Log file Viewer
#pypa logs for Wednesday the 10th of June, 2015
[00:39:23] <ionelmc> tos9: or just use the rewrite, it works fine IMO, it's just that dstufft didn't have time to review it yet :-)
[00:42:07] <ionelmc> tos9: eg: pip install https://github.com/ionelmc/virtualenv/archive/develop.zip
[08:24:36] <nikolaosk> setup.py http://ix.io/j22 MANIFEST.in http://ix.io/j23 egg contents http://ix.io/j24 egg's SOURCES.txt http://ix.io/j25 bdist_egg output http://ix.io/j26
[08:30:14] <ronny> a readme should be read into the long description, then its fed into the pacakge metadata
[08:31:22] <nikolaosk> so, I guess there is no way to include package files on the top level of an egg, right?
[08:33:44] <nikolaosk> ultimately what I try to do, which may be out of the setuptools/distutils scope
[08:36:56] <jchen> hi, namespace packages aren't making any sense to me. when i have two NS packages installed together I can't import the first NS package. What am I doing wrong?
[08:38:08] <jchen> https://github.com/podhub-io/website/blob/master/podhub/__init__.py and https://github.com/podhub-io/meh/blob/master/podhub/__init__.py ?
[08:39:37] <nikolaosk> have you heard of the scrapy project? I write spider modules and upload them to a daemon as eggs
[08:42:29] <jchen> podhub.meh is installed as a dependency in setup.py, i'm currently working podhub.website with setup.py develop
[08:42:50] <jchen> i tried making an sdist and installing that in case there's a misunderstanding of how linking works in develop
[08:47:05] <jchen> hm, nvm, it's working for some reason now. i deleted the virtualenv and made a new one
[08:53:13] <ronny> nikolaosk: if you run the eggs separately, you just need a nosite python and activate the ones you want ^^ (i suspect you dont use pip , so things should be fine)
[09:01:22] <nikolaosk> can I just prepend it to sys.path in the toplevel __init__.py of my package without creating a mess
[09:03:17] <nikolaosk> I add a vendor/ folder next to my package, include it in setup's packages list
[09:04:04] <ronny> given that you use eggs, just add them to a new folder- and activate that folder as site in the subprocess?
[09:04:29] <nikolaosk> and if, say, my actual package is "autojournalistics", I put in autojournalistics/__init__.py a sys.path[:0] = ...
[09:16:45] <ronny> nikolaosk: good luck then, but plaase keep in midn that what you do is a) messy, b) is already solved by the tools in a different way - so you are fighting windmills
[09:29:31] <ronny> all you need is a python script thats started siteless and given an egg , a site and a entrypoint - thne you jsut enable pkg_ressources, and use that to add the other eggs to sys.path
[09:37:10] <nikolaosk> my mistake, I should have said "can't make the daemon ran by / run a siteless python"
[09:38:13] <nikolaosk> but why do I need it to be siteless? will I then need to put _all_ my dependencies in eggs
[09:39:44] <ronny> nikolaosk: thats kind of the intent of the whole egg format, all deps are eggs, differnet processes can run different sets of eggs
[09:40:29] <ronny> and if you use easy_install to isntall the daemon, everything there should be eggs to begin with
[09:53:14] <nikolaosk> "subprocesses can add custom site folders" but my project is deployed as a zipped egg
[10:32:58] <ronny> nikolaosk: also keep in mind that egg is bascially a dead format, scheduled for demise
[11:35:46] <nikolaosk> its developers are onto something proprietary in the cloud so the forgot about it
[11:42:22] <nikolaosk> how does this look: open(os.join(os.path.split(__file__)[0], 'some package_data file'))
[11:54:45] <ronny> dstufft: can you ensure that the next version of wheel will no longer have the version numbers in the inner folders (dist-info/data/...)
[11:55:40] <ronny> (right now there is no way to from within a file of package directly open its dist-info without searching sys.path)
[12:08:44] <kenpachi> i often see try except blocks attempting to import setup from setuptools with a distutils fallback. how does the distutils version of setup handle keyword args introduced by the setuptools version of setup? does it fail gracefully, or does it raise an error? I'm trying to decide whether it is worth offering a distutils fallback
[12:11:50] <ronny> kenpachi: print warnings, please done do the distutils fallbac, it creates a different kind of mess ^^
[12:17:43] <kenpachi> ronny: I don't think I will, I was trying to find good reasons to do so but haven't found any yet, at least for new packages anyway
[12:25:33] <ionelmc> you'd have to severely cripple your setup.py to make it fallback on pure distutils
[12:25:39] <ronny> kenpachi: also for all pure python packages, make wheels, if possible universal ones, it cuts install times and makes callign setup.py unnecessary in many cases
[12:29:59] <kenpachi> since the python docs explicitly recommend setuptools, is it fair to say that setuptools is now "the standard"?
[12:36:35] <ronny> kenpachi: for now yes, well, the setup part of setuptools is, the way it installs as eggs got superseeded by managed pip installs and virtualenvs
[12:44:10] <kenpachi> FYI to all - it might be worthwhile trying to get this popular stackoverflow answer updated to reflect the current best practices, as describes distutils as the standard and could be misleading: http://stackoverflow.com/questions/6344076/differences-between-distribute-distutils-setuptools-and-distutils2
[12:49:22] <Wooble> The whole premise of the question is outdated; who automatically runs 2to3 these days?
[12:50:40] <Wooble> kenpachi: by "standard" he clearly means "in the stdlib". That's not going to change any time soon.
[12:52:20] <kenpachi> I would change the line "Distutils is still the standard tool for packaging in Python"
[12:53:18] <Wooble> Feel free to suggest an edit. (I'd vote to close the question as "too localized" but they've removed that option.)
[12:53:49] <kenpachi> Just a gentle suggestion only because this answer will likely be getting a lot of traffic.
[13:00:13] <Wooble> I've gained 788 reputation since the last time I logged in, and I haven't even posted any new answers in 9 months. skillz.
[13:11:20] <nickjj> there's no shortcuts available to get up to date package versions for everything in your requirements file at once right?
[13:13:33] <nickjj> produces an output like this: https://gist.github.com/nickjj/f78674a55f2c96be9ca5 if you're curious
[13:37:29] <tdsmith> does anybody know why someone would be seeing a traceback like this, where pip._vendor.distlib.scripts can't be imported after installing a pip egg https://github.com/Homebrew/homebrew/issues/40516#issuecomment-110678188
[14:05:31] <ionelmc> i suspect it's the one with the dlopen, but there's only one way to know for sure
[14:13:38] <tdsmith> thanks; my sense of order in the universe is restored. (next question is "why are python builds broken on the new os x" :/ which is hard to troubleshoot without access)
[20:38:55] <jaraco> oh, interesting. Apparently I’ve bumped pmxbot to pymongo3 already. Issue might be in the deployment.
[20:43:51] <ronny> dstufft: i see, i asked a while back if the version numbers could be dropped from the directories inside of a wheel
[20:50:39] <lambacck> jaraco: http://chat-logs.dcpython.org/channel/pypa still has a stack trace showing
[20:50:45] <tdsmith> ionelmc: you were right! the real problem was that the _ssl module wasn't being built (because cpython's openssl detection code needs coaching) and that was giving rise to the real ImportError
[21:18:43] <ronny> dstufft: version numbers in stuff like dist-info paths only make sense if there is multi version install in a clunky way
[21:48:13] <jaraco> aclark: pmxbot when it’s updated gets the latest pymongo. Pymongo3 was recently released with backward incompatible changes.
[21:48:36] <jaraco> There were fixes to address that in the codebase, but they hadn’t been released or tested.
[21:48:55] <jaraco> After testing them and adding a couple more fixes, a refreshed deployment fixed everything.
[23:09:09] <radix> lots of packages come with optional C extensions that fall back to pure Python code, and I just want to force the fallback.
[23:10:15] <tomprince> There might be a dance you can do by calling setup.py by hand, to just install parts of packages.
[23:11:11] <ionelmc> radix: something like this https://github.com/ionelmc/python-lazy-object-proxy/blob/master/setup.py#L28-L56 ?
[23:12:28] <tomprince> ionelmc: The question is how to install existing packages that already have that fallback.
[23:12:40] <ionelmc> there are some other variantions on that custom command, eg: https://github.com/simplejson/simplejson/blob/master/setup.py
[23:14:34] <tomprince> That will install the extension if there is a C compiler and headers. How, as a user, do you prevent that, for packages that can work without.
[23:14:48] <radix> ionelmc: that still unconditionally *try* to build the C extension, so it's not a solution
[23:15:40] <ionelmc> would using a custom PATH (that doesn't have any gcc) be a acceptable workaround?
[23:16:08] <tomprince> Is that enough? Or does distutils know where the compiler that compiled it lives?
[23:16:22] <ionelmc> other way is to use crippled virtualenv (that doesn't have the include dirs or whatever)
[23:16:28] <radix> maybe that'd work. I'd love to be able to specify it on the pip command line in requirements.txt
[23:17:44] <radix> because I don't trust C extensions, and would prefer to use them only when strictly necessary.
[23:18:14] <radix> I have had many segfaults over the last 15 years which could be solved by disabling some crappy C optimization module. :)
[23:21:41] <tos9> Is pip>=6.0 a sane thing to put in setup_requires for things that use environment markers, or will that cause setuptools to be the thing that tries to do the install, and therefore the world to end
[23:30:07] <tos9> dstufft: what I want is for stuff to work I guess so I've already not gotten what I want :(
[23:30:50] <dstufft> tos9: lower your expectations until they match reality, instant recipe for contentment!
[23:32:05] <tos9> apparently it means "hey you need environment markers now, and debian still ships old-as-hell pip"
[23:34:41] <dstufft> there's not a great way to resolve that currently. Probably we should add something that you can say that you require pip >= X.Y and error out if it doesn't match that
[23:36:17] <tos9> and so if I add install_requires in an if block, like I had before, then they'll work too?
[23:36:51] <tos9> pip 1.5 will grab the wheel, not respect the environment marker, and not look at install_requires either?
[23:37:07] <dstufft> I mean yes, that still works, and will always work as long as setup.py is a thing
[23:37:34] <dstufft> you'll want to use the ability of wheel to override the install_requires probably
[23:38:33] <dstufft> https://github.com/pypa/twine/blob/master/setup.py // https://github.com/pypa/twine/blob/master/setup.cfg
[23:42:45] <dstufft> depends on what your defintion on right is, the extra_requires thing is the intended "right thing", but well, legacy software