pmxbot IRC Log Viewer

[08:36:03] <ggherdov`> Hello. Is there an environment variable whose existence can tell you "yes we are inside a virtualenv"?

[08:36:03] <ggherdov`> I am looking at some traces from a process, and all I know is its "env" dump. I'd like to know if "activate" was sourced or not before it run.

[10:56:02] <pf_moore> ggherdov`: You should be able to check VIRTUAL_ENV

[10:58:48] <ronny> re

[12:23:07] <SamuelMarks> hi

[12:24:21] <SamuelMarks> I keep getting ImportError's when installing my simple package (that depends on a few others), because pip isn't installing their dependencies. How to fix? - http://stackoverflow.com/q/28540839

[13:10:47] <ggherdov`> pf_moore: thanks

[13:15:17] <jezdez> dstufft: ping

[14:20:33] <nanonyme> I have this idea of doing automatic .exe/.egg->wheel conversion with pip for dependencies to allow installing compiled versions for unmaintained packages. Is there some extension point in pip I could use for this?

[14:21:15] <nanonyme> wheel would obviously be used if already available

[14:21:47] <nanonyme> dstufft, opinions whether totally absurd?

[14:24:34] <nanonyme> Also how should a situation like https://pypi.python.org/pypi/lxml/3.4.1, https://pypi.python.org/pypi/lxml/3.4.2 where newest has no wheels, older does be resolved? From Windows user point of view it would most likely make more sense to fallback to 3.4.1 rather than the source tarball

[14:53:17] <ionelmc> nanonyme: wouldn't that just create more confusion, eg "why was older version installed? damn buggy pip"

[14:53:58] <ionelmc> and for windows, there's appveyor, it's free, it has all the compilers and major python versions

[14:54:11] <ionelmc> you have no excuse if you don't provide wheels for windows, really.

[15:54:04] <ggherdov`> Hello. When I do "virtualenv --system-site-packages", what is the mechanism by which the virtualenv inherits the global site-packages? Is it $PYTHONPATH involved in that in some way, or do they go directly into sys.path?

[15:57:02] <ggherdov`> ionelmc: i see, thanks

[16:05:30] <jaraco> pong ronny (from twitter)

[16:35:43] <ronny> re

[16:36:06] <ronny> jaraco: entirely missed the irc client (was hacking)

[16:36:53] <ronny> (i was only monitoring the ml and twitter, since you dont idle)

[16:48:10] <jaraco> ronny, I'm back now.

[16:48:48] <jaraco> I used to idle, but then my company switched to Slack, so I have a separate client for work as for everything else.

[16:48:59] <ronny> i see

[16:49:02] <jaraco> You mentioned the topic in pypa, but I'm not quite sure to what you refer.

[16:49:16] <ronny> jaraco: setuptools_scm

[16:52:37] <jaraco> ronny, I'm on board with doing it. What can I do to help?

[16:55:25] <ronny> jaraco: feature check on hgdistver, and if it checks out letting me in pypa on bitbucket so i can move the hgdistver repor to pypa/setuptools_scm

[16:56:58] <jaraco> right. As I said, I'll do that. It'll take some time. There's no reason to be blocked on migrating the tool, though. I'll file tickets with whichever project is active.

[16:58:20] <jaraco> ronny, Does hgdistver support both git and hg for the same project?

[16:58:44] <ronny> jaraco: it detects the scm from the working directory

[16:58:47] <jaraco> That is, consider a project that's hosted in both git and mercurial; can hgdistver handle making releases from either checkout?

[16:59:05] <jaraco> is the interface the same such that the project can be agnostic to which SCM hosts the code?

[16:59:12] <ronny> yes

[16:59:16] <jaraco> Excellent!

[16:59:29] <ronny> it supplies a fiel finder for git and hg

[16:59:50] <ronny> and when you use the get_version_from_scm=True argument it detects the version based on tags

[17:00:20] <ronny> and if the workir is not availiable it tries sdist metadata, hg archial metadata

[17:00:42] <ronny> but for the real integration i'd like to to be unnecessary to run on the sdist

[17:00:50] <ronny> (which is the setuptools work part)

[17:01:06] <jaraco> I'd support that work, though I haven't scoped it or even created a ticket for it.

[17:01:06] <ronny> but i suspect it wi stay in hack-mode until setuptoolks is upgraded

[17:01:17] <jaraco> I would be glad to review work to that end.

[17:01:21] <ronny> we are still at the planing stage

[17:02:58] <jaraco> ronny, I just released pytest-runner 2.3 using hgdistver. So far, everything works as I would expect.

[17:02:59] <jaraco> !m ronny

[17:02:59] <pmxbot> you're doing good work, ronny!

[17:04:18] <ronny> :)

[17:06:13] <ronny> jaraco: so how well does the whole thing check out with you

[17:06:52] <ronny> jaraco: im getting the vibe that its a good idea to move to the blessed name early, fix occuring issues while making new releases, and then when the setptools side provides better static information do a 1.0 release

[17:08:09] <jaraco> If it were up to me, I would make the initial release 1.0. Anything less than 1.0 says to me it's beta. If it's endorsed and users can depend on the interface, it's 1.0.

[17:08:32] <jaraco> I try not to reserve version numbers for specific changes, as inevitably, other changes will come up.

[17:08:46] <jaraco> I do wholly endorse moving the project name as early as possible (less flux for me).

[17:09:30] <jaraco> ronny, have you seen the versioning parameters that hgtools takes? https://bitbucket.org/jaraco/hgtools/

[17:09:47] <jaraco> 'increment' and 'version_handler' ?

[17:09:52] <jaraco> There might be others, yet undocumented.

[17:10:41] <jaraco> I use increment in some of my projects, though not frequently.

[17:11:06] <ronny> jaraco: yes, it seems a bit overpowered, i'd like to endorese a streamlined simple interface but im open to ideas

[17:11:13] <ronny> have you seen how i use setup keywords?

[17:11:15] <jaraco> I don't use version_handler, though I know some users of hgtools do.

[17:11:30] <ronny> (i use setup keywords to add extra parameters)

[17:12:34] <ronny> also back in about 15, dinner was just made for me

[17:12:39] <jaraco> I did see mention of that. I avoided that approach because I wanted to avoid proliferating options into a public namespace (setup parameters).

[17:13:22] <ronny> i see

[17:13:41] <jaraco> It felt more appropriate for all options to hgtools to be encapsulated in a namespace somewhere, and I found I could readily re-use the single parameter 'use_vcs_version'.

[17:14:04] <ronny> hmm, then i will adopt that as well

[17:14:10] <jaraco> But again, I'll state my preference, but defer to your design.

[17:15:18] <ronny> its a good point

[17:16:06] <ronny> i want to handle such details with care

[17:16:35] <jaraco> We can iterate on some 0.x releases prior to announcement.

[17:16:56] <ronny> jaraco: my idea is to be pre 1.0 for another 1-2 months to iterate on such detais

[17:17:14] <ronny> but i'd like to announce a early beta to get in more user input as well

[17:17:47] <jaraco> Sounds good to me.

[17:17:49] <jaraco> !rubberstamp

[17:17:49] <pmxbot> Bad credit? No credit? Slow credit? APPROVED!

[17:19:01] <ronny> jaraco: so i suppose we start with moving hgdistver to pypa as setuptools_scm

[17:19:13] <ronny> jaraco: who else should i add as owner on pypi?

[17:20:02] <jaraco> ronny, You may want to read through closed hgtools issues too, to see if they have any relevance for hgdistver.

[17:20:04] <jaraco> Such as https://bitbucket.org/jaraco/hgtools/issue/7/hgtools-fails-to-invoke-hg-on-mac-os-x-in

[17:21:14] <jaraco> ronny, right now, I'm the only owner of hgtools on pypi. You might consider adding jezdez, as he's the author of setuptools_hg, from which hgtools was forked.

[17:22:24] <ronny> do you use ok, i'll add you and jezdez as additional owners ?

[17:22:45] <jaraco> Sounds like a plan.

[17:23:25] <dstufft> jezdez: pong

[17:24:24] <ronny> jaraco: your name there is jaraco?

[17:24:34] <ronny> also who adds me to pypa on bb

[17:25:33] <ronny> hmm, btw, do we have ci slaves that run win32/osx?

[17:27:31] <jaraco> ronny, I may be able to add you. I'll check.

[17:27:42] <jaraco> If we have CI slaves, I'm not using them.

[17:28:55] <jaraco> ronny, You're now admin on bb://pypa

[17:30:35] <jezdez> dstufft: hey, mind resetting the upload locks for django-appconf?

[17:30:41] <jezdez> people are kinda going on my nerves

[17:31:17] <jezdez> ronny: sure +1

[17:31:34] <jezdez> jaraco: I forgot hgtools was a setuptools_hg fork, sigh

[17:31:40] <jezdez> long time not thought about that :)

[17:31:57] <jezdez> good thing we combine forces :)

[17:32:11] <ronny> wee :)

[17:32:47] <jezdez> ronny: indeed

[17:39:06] <ronny> jaraco: i'll adapt the use_scm_version=True/a dict approach

[17:39:12] <ronny> and then do a initial release

[17:39:13] <dstufft> jezdez: yea, will be a few

[17:39:17] <dstufft> jezdez: just woke up

[17:39:23] <ronny> good mornng dstufft

[17:48:00] <ronny> jaraco: oh, the issue you linked dosnt apply, i always copy the env ^^

[17:51:48] <ronny> omg

[17:51:50] <ronny> hmm

[17:52:55] <ronny> setuptools_scm - can a distribution actually use itself as a setup_requires, or was that a msiitake on my side since it worked with hgdistver due to previous releases

[18:01:38] <dstufft> jezdez: you should be reset now

[18:05:17] <linovia> mmm

[18:05:59] <linovia> dstufft: do you know who's in charge of pythonhosted.org ?

[18:07:20] <linovia> the static files there are giving a http 500 :(

[18:14:17] <jaraco> ronny: I was never able to get hgtools to use itself in setup_requires, even after releases of hgtools were in the wild.

[18:15:01] <jaraco> I instead had to configure hgtools to get its version info by importing itself and calling the API directly.

[18:15:23] <jaraco> That's not to say it can't be done, but only that I never succeeded.

[18:15:59] <dstufft> linovia: which files?

[18:16:12] <dstufft> oic

[18:19:00] <dstufft> linovia: should be fixed now

[18:21:00] <linovia> dstufft: thanks !

[18:21:03] <ronny> jaraco: it worked for hgdistver by accident i just recreated a manifest.in and added a call

[18:21:42] <ronny> jaraco: i have a release_ready version that uses the use_scm_version mechanism and supports truth vaues and passing keys in a dict

[18:32:50] <jezdez> dstufft: thanks, uploaded all releases that still correctly build sdists

[18:33:01] <ronny> hmm

[18:33:14] <ronny> ok, i have a release candidate, anyone here with a mac and devpi?

[18:55:17] <nanonyme> ionelmc, it doesn't help zilch with lxml if you have the proper compiler. It's a real PITA to compile on Windows. You have to statically link several libraries against it to get it working. Manually

[18:55:29] <nanonyme> ionelmc, the tarball is *completely* useless as a default

[18:55:51] <ionelmc> nanonyme: are you saying it compiles but it's borken?

[18:56:06] <nanonyme> I'm saying the tarball can't be compiled as is on Windows

[18:56:38] <nanonyme> You have to extract it, manipulate the setup.py to enable static linking, download several extra packages and statically link to get the end result

[18:57:00] <nanonyme> The source tarball only works with *nix as is

[18:57:36] <ronny> nanonyme: upstream win32 patches?

[18:58:12] <nanonyme> ronny, would make more sense to fork lxml tbh

[18:59:40] <tdsmith> i'm on the sidelines here but this sounds like a lxml packaging bug; if a package doesn't support windows that doesn't seem like a problem pypa should solve

[18:59:43] <nanonyme> http://lxml.de/build.html#static-linking-on-windows the *only* reasonable installer packages for lxml on PyPI are eggs, .exe's and wheels for Windows

[19:01:37] <_habnabit> ronny, i don't know if you fixed it for your new project, but there's a bug in your original codebase wherein it will look in parent directories for the .git/.hg directory, which causes problems if you're pip installing while inside a different repository

[19:03:50] <nanonyme> ronny, well, sure, you could fork libxml2 and xslt, then try to get lxml merge them into their codebase

[19:04:46] <nanonyme> Which they would then reject so you'd end up forking lxml too

[19:05:30] <nanonyme> And I'm not even sure if the Windows binaries can be freely bundled in arbitrary projects

[19:06:17] <nanonyme> So yeah, again, binary distributions are the only sane solution for lxml on Windows

[19:08:06] <ronny> _habnabit: good find, thats not fixed yet

[19:09:10] <ionelmc> nanonyme: lxml-3.4.1-cp27-none-win_amd64.whl - pretty sure that was compiled

[19:09:53] <ionelmc> no source patching, just `pip wheel lxml`

[19:09:54] <nanonyme> ionelmc, yes, statically like I described. It contains libxml2 and xslt

[19:10:01] <nanonyme> I doubt that

[19:10:08] <ionelmc> nanonyme: ok, so what's the issue?

[19:10:40] <ionelmc> oooh

[19:10:41] <ionelmc> damn

[19:10:45] <ionelmc> you're right

[19:10:46] <ionelmc> xD

[19:10:56] <ionelmc> must have had that from pypi

[19:23:54] <nanonyme> ionelmc, yeah. And currently as 3.4.2 has no wheels, pip doesn't use the properly working wheel from 3.4.1 and doesn't try to convert the exes to wheels (which would probably also work) but just tries to compile the tarball which is a guaranteed failure

[19:24:24] <ronny> _habnabit: what problems occur?

[19:24:40] <ronny> (i just created some tests that should fail if that was an issue but they dont

[19:24:59] <ionelmc> nanonyme: can't the lxml devs fix it?

[19:28:48] <nanonyme> ionelmc, well, they created .exe's and .wheel's for 3.4.1 but only .exe's for 3.4.2. I'm assuming decision was political. easy_install supports .exe's but no wheels, pip supports wheels but no .exe's

[19:30:06] <nanonyme> IOW do please kill easy_install from future releases of setuptools

[19:32:26] <nanonyme> Seems otherwise pip will never properly take off except on Linux

[19:33:41] <apollo13> nanonyme: I asked for that, they didn't like the idea

[19:34:45] <ronny> droping support for generating eggs might be interesting while also supporting loading/importing wheels for setup_requires

[19:38:02] <ronny> bbl, having a drink

[19:39:53] <nanonyme> ronny, you'd have to drop generating .exe's too

[19:40:21] <nanonyme> Otherwise easy_install has an edge on pip

[19:41:15] <nanonyme> Alternatively pip could develop support for installing .exe's

[19:43:19] <dstufft> well

[19:43:28] <dstufft> pip is already a much larger share than easy_install

[19:43:53] <dstufft> and that includes the fact that sometimes ``pip install`` will also do an easy_install implicitly

[19:44:24] <dstufft> http://d.stufft.io/image/1n2f1W3r3M3q

[19:46:19] <nanonyme> dstufft, what's that, downloads from PyPI?

[19:46:44] <dstufft> yea

[19:46:49] <dstufft> by installer

[19:47:18] <nanonyme> But yeah, sure, pip can install 99% of useful packages. I'm also trying to promote at work that people would avoid .egg's and use tarballs instead if they have no compiled binaries inside them

[19:48:24] <dstufft> (I mention this mostly to say that arguments about how we need X feature to "take off" is the wrong argument, I'm all for adding useful features without thinking too hard about if that feature is one we should support or not)

[19:50:02] <nanonyme> I just sometimes get the feeling projects move intentionally or accidentally away from pip rather than towards it these days

[19:50:45] <nanonyme> It obviously helps much most Python packages have tarballs, possible conversion rate there is very high

[19:53:21] <_habnabit> ronny, it'll take tags from the containing repo

[19:53:36] <_habnabit> ronny, this is why vcversioner always passes --git-dir

[19:58:47] <nanonyme> dstufft, tbh lxml and psycopg2 can easily be deal-breakers for a Windows user. If those aren't available in the format you need, you change package manager or operating system

[20:00:10] <nanonyme> (latter to the degree of moving people away from Windows which may not be such a bad thing)

[20:02:32] <nanonyme> (okay, apparently people go to quite some lengths to avoid changing OS https://github.com/nwcell/psycopg2-windows)

[20:06:57] <ronny> _ah, i see what you mean

[23:44:21] <Guddu> I tried to install reportlab after installing setuptools the commands were as follows

[23:44:21] <Guddu> pip install setuptools-12.1-py2.py3-none-any.whl --no-index --find-links /GDD_Prerequisites

[23:44:28] <Guddu> pip install reportlab-3.1.44.tar.gz --no-index --find-links /GDD_Prerequisites

[23:44:43] <Guddu> The reportlab install however gives this error ---> http://dpaste.com/1HHXT4R

[23:44:47] <Guddu> What could be the issue?

[23:46:48] <dstufft> Guddu: what verision of pip

[23:47:17] <Guddu> dstufft, pip-6.0.8-py2.py3-none-any.whl is what i used

[23:47:58] <Guddu> This is on RHEL 6.5

[23:48:39] <dstufft> so the high level problem is that for some reason setuptools isn't available when the reportlab setup.py is being installed, why that's the case I'm not sure...

[23:49:47] <Guddu> dstufft, setuptool is not available or the right version of it is not available? How can i check this?

[23:50:03] <apollo13> reportlab is afaik supposed to work without setuptools

[23:50:13] <apollo13> https://bitbucket.org/rptlab/reportlab/src/5214fe281f6d7647d884020971cc7aad175e2593/setup.py?at=default#cl-46

[23:50:17] <Guddu> apollo13, It failed without setuptools :-(

[23:50:53] <Guddu> version 3.1.44

[23:52:25] <apollo13> I mean they have install-requires which should force you to have setuptools, maybe try an older version?

[23:52:54] <dstufft> pip requires setuptools

[23:52:56] <dstufft> we call egg_info

[23:52:57] <apollo13> or an up2date setuptools

[23:53:11] <apollo13> 3.1.44 is old after all :)

[23:53:40] <dstufft> Guddu: Umm, trying to figure this probably out is probably going to be hard-ish, you'll probably need to modify the reportlib sdist to drop a pdb into the setup.py

[23:54:22] <Guddu> dstufft, What is dropping a pdf in setup.py. Not sure if i understand that.

[23:54:59] <apollo13> pdb, the python debugger

[23:55:21] <Guddu> apollo13, This to colllect more data? to find out what is happening?

[23:56:40] <Guddu> Will this error happen for reportlab alone or for everything that i try to install?

[23:57:27] <dstufft> unsure

[23:58:45] <Guddu> dstufft, How do i go about that pdb thing?

[23:59:35] <dstufft> Guddu: import pdb; pdb.set_trace()

Log file Viewer

Help | Karma | Search:

#pypa logs for Monday the 16th of February, 2015