Log file Viewer
#pypa logs for Monday the 12th of May, 2014
[16:15:34] <marianoguerra> when installing with pip install -t it installs to the suplied directory but if available system wide it tried to uninstall it and fails if I don't have permissions
[16:16:11] <marianoguerra> aclark: I can imagine that, but maybe some people in other timezone will see it now
[16:26:37] <aclark> dstufft: can you add trove classifiers? This ticket was closed for not-a-very-good-reason IMHO: http://sourceforge.net/p/pypi/support-requests/366/. We are gearing up for a Plone 5 release and are definitely going to need and user a "Framework :: Plone :: 5.0" classifier sooner rather than later
[16:27:56] <aclark> dstufft: alpha is out, i guess i could start releasing add-ons for 5.0 if I had to…
[16:29:02] <Ivo> you add plone 5 packages that are marked as Framework :: Plone and then point to them and say look here! THese could be more sepcific!
[16:29:38] <dstufft> aclark: uhh, well i'm not very likely to overrule Richard. I can poke him later today when he's awake about it
[16:31:40] <aclark> Here's my thing: If a known-good community asks for a classifier and that classifier is not controversial, give it to them.
[16:34:26] <dstufft> but yea, most of the troves are pointless, and the ones that aren't pointless would be better served by a more structured field
[16:35:28] <dstufft> aclark: ok so teminology aside :) Is something written for plone 4.2 unlikely to work with 4.3?
[16:35:28] <Ivo> come to think of it its a pity we don't have a separate field for specifying what version of python something hopes to be compatible with
[16:36:44] <dstufft> aclark: also the side of my face hurts becuase I had a root canal today so I'm probably grumpier than normal
[16:37:34] <marianoguerra> Ivo: doing sudo pip install jinja2 and then pip install -I -t ./lib jinja2 gives:
[16:37:35] <marianoguerra> OSError: [Errno 13] Permission denied: '/usr/lib/python2.7/site-packages/Jinja2-2.7.2-py2.7.egg-info/not-zip-safe'
[16:38:50] <dstufft> Ivo: nothing other than the novacaine or w/e the hell they shoot into your mouth now adays
[16:40:11] <Ivo> just looking at https://en.wikipedia.org/wiki/File:Root_Canal_Illustration_Molar.svg looks painful
[16:45:56] <marianoguerra> Ivo: I think it's simpler to just install the deps inside a folder for each project and then set the path
[16:47:48] <Ivo> marianoguerra: with virtualenv you won't need to worry about specifying a folder or setting a path
[16:49:14] <marianoguerra> Ivo: I just want to know if that is a bug or not, it looks to me, if not I would like to know what's the expected behaviour of the -t option
[16:49:36] <aclark> dstufft: more to the point, i requested the existing classifiers which MvL created for me and 4.3 did not even exist at the time. I think Richard is just inadvertently coming out of left field with a reasonable-policy that doesn't really apply to us.
[16:49:59] <marianoguerra> mainly because I've seen also it trying to uninstall the systemwide version of the same package if I try to install it somewhere with -t
[16:54:40] <marianoguerra> given the description here: https://pip.pypa.io/en/latest/reference/pip_install.html#cmdoption-t I would expect to do just that and nothing more
[17:15:35] <dstufft> aclark: to be clear, I don't really see a point in having versioned classifiers like that unless there was a big compatability break (ala Python2 / Python3) that makes them essentially different things.... but I also don't see a point in not giving a 5.0 one if there are already other versions
[17:21:44] <dstufft> aclark: we do generally have a policy that requires that classifiers will have some level of use before we add them (or else every one will try to get a classifier for their project), I just don't really know that I'd bother trying to enforce hat here since there are already classifiers for it.. unless we have reason to believe that plone 5.0 sucks and nobody is going to use it, which i'm guessing isn't the case ;)
[17:24:46] <aclark> dstufft: no reason to enforce that here IMHO, this is just a routine follow up to a request i made years ago. only diff is it didn't come directly from me this time and was roundly rejected :-)
[17:31:17] <GiLgAmEzH> Hi all! i'm creating a venv with create() https://docs.python.org/3/library/venv.html#venv.EnvBuilder.create Is possible activate it from the same .py where i'm creating the venv
[17:36:08] <Ivo> GiLgAmEzH: to my knowledge people haven't tried to explicitly make that possible yet. you can see even the example uses Popen to run things in the new env
[20:31:42] <adamcunnington> Hi, can anyone help with this beautifulsoup4 installation error? http://paste.ubuntu.com/7449722/
[22:43:45] <Ivo> dhellmann: had you run into troubles with namespace packages & editable installs with pip in openstack?
[22:45:40] <dstufft> dhellmann: I pointed Ivo at you :) I recall oslo was having problems with namespace packages and I think Ivo is trying to understand them and see if maybe the general problem can be fixed
[22:46:15] <dstufft> There's a good chance responses will be delayed or lost though fwiw Ivo , there's a really high chance dhellmann is in atlanta ATM at the openstack summit :)
[22:49:44] <dstufft> Instead of going to the summit I'm writing a PEP and getting high on painkillers
[22:50:02] <Ivo> e.g. my dad's employer will allow him to negotiate for discounts on any conferences and courses and such that make him an awesomer employee
[22:54:28] <elarson> Ivo: we use them at work and have had an issue where projects in the same namespace as the project I'm working on need to be installed manually
[22:55:16] <elarson> for example, I'm working on a project foo and have a foo.client package and foo.utils
[22:55:57] <elarson> I use a dev_requirements.txt that has -e . (for project foo) and then has foo.client==0.3 and foo.utils==1.2
[22:56:39] <elarson> when I try to install foo.client to work on some code within the context of the foo package, it doesn't work as expected
[22:57:49] <elarson> there ends up being a foo directory in my venv's site packages that ends up stealing the namespace
[22:58:21] <elarson> my resolution ends up being to remove any foo packages and install them all manually as editable
[23:00:27] <mugwump> that was the conclusion I came to when I tried to break up a package into separate distributions before, anyway
[23:01:11] <elarson> mugwump: well that is what pip does (if I understand it correctly). it installs the package by unzipping the package vs. what setuptools does by default by referencing the egg
[23:02:56] <elarson> all that said, if there is something related to namespace package that ever needs testing, feel free to ping me to try things out.
[23:03:30] <dstufft> elarson: are you able to create some fake test packages and provide steps to reproduce the problem?
[23:04:02] <dstufft> I think that's what Ivo is really hoping for here, so we can at least properly understand the problem
[23:04:27] <dstufft> to figure out if it is a fundamentally unsolvable problem or if it is just an implementation problem
[23:05:01] <dstufft> the original namespace ticket for pip predates both Ivo and myself by several years I think :)
[23:11:36] <mugwump> so, this means that all the modules need to be installed in the exact same package
[23:12:43] <mugwump> I don't know of any PyPI distribution that ships in parts like this, as would be common on, say, CPAN
[23:15:14] <elarson> Ivo: so in the foo project, we'd install foo.client from a package via a requirements.txt, but not as editable yet
[23:15:43] <elarson> I think that would be like source venv/bin/activate && cd ../foo.client && python setup.py install
[23:16:54] <elarson> Ivo: then when you go back to the foo package and try to import something within it (I have a run.py in my example), you get an import error
[23:18:29] <elarson> Ivo: sorry, I did install that into a virtualenv called 'venv' in my foo directory
[23:29:17] <elarson> Ivo: let me know if that makes sense. I'll try to put a script or repo together to reproduce the issue