Log file Viewer
#pypa logs for Friday the 21st of February, 2014
[01:34:57] <dstufft> qwcode: can you fork my gist and make changes to what it should be and i'll just copy/paste it in?
[02:13:14] <Ivo> Did anyone know that the form multipart encoding of distutils' upload has been broken ever since it was first implemented?
[02:37:57] <dstufft> the req.py split and the pep8 cleanup makes it kind of annoying to merge between them
[02:40:57] <qwcode> dstufft, neither pip or virtualenv's rst is rendering on pypi, which is annoying
[02:41:44] <qwcode> virtualenv develop has a fix for it https://github.com/pypa/virtualenv/commit/d1d4b7039d55b6793b576216b89ff4a36ce87e24
[02:45:58] <qwcode> dstufft, maybe cause pip has this in the quickstart First, :doc:`Install pip <installing>`.
[02:58:59] <qwcode> dstufft, is it safe to just edit the description in pypi to confirm what's the problem? I'm editing virtualenv now, but have never done that before
[03:01:52] <qwcode> dstufft, ^ I'll fix in develop and 1.5.X inclined to remove the quickstart from the long description if it means it has to be dumbed down
[03:02:24] <dstufft> qwcode: might make sense to make README.rst a nice landing page for both github and PyPI
[04:57:06] <Alex_Gaynor> dstufft: eh, wat? https://travis-ci.org/pyca/cryptography/jobs/19310446#L700
[05:44:08] <Alex_Gaynor> dstufft: As far as I can tell every invocation of pip 1.5.3 triggers a warning
[06:27:00] <qwcode> dstufft, I just dropped it from the check, but still mention --build in the message if they use the other 3 options
[06:30:35] <qwcode> dstufft, yes, we could compare if it's different than pip.locations.build_prefix. that's probably ok. if someone is pinning the build_dir in the config file for some reason, the message could get annoying, but they are the people we are trying to inform
[06:31:22] <Ivo> you could use nargs='?'; if its just --build, it can be set to True, in which case you can set it to build_prefix; if it has an arg, you can set it directly to that
[06:33:31] <qwcode> Ivo, I don't follow. I think it's just a matter of asking whether options.build_dir != pip.locations.build_prefix in the install command
[06:35:15] <Ivo> well you have three use cases; 1. no build_dir, which will become default; 2. build_dir is default build_prefix; 3. build_dir is a custom path. If you used, say [False, None] as sentinal values you could check for both 1. and 2. in 1.5.x
[06:45:12] <qwcode> Ivo, you're concerned that we should log the warning, if they happen to set it manuallly set it to the default?
[06:46:04] <Ivo> qwcode: you could set it to None, but give them the option to set it to the previous default, if they relied on that
[06:47:42] <Ivo> e.g it starts off as None; if user passes --build, its set to default, if they pass --build <x> its set as that
[06:52:46] <qwcode> Ivo, our idea is that the build dirs should have never been fixed, and there's no reason for people to control the location, so wanting to get rid of all this, and use tmp build dirs
[13:03:32] <dstufft> http://bugs.python.org/issue20721 for those following along at home wrt pip and CPython 3.4
[17:24:53] <apollo13> actually it looks like it fails as soon as the wheel is built from a src tar as compared to a git checkout, no idea why yet
[17:28:59] <apollo13> the issue appears (at least from what I can tell) to be that a wheel generated from the django sdist installs data files into the virtualenv root, whereas when I generate a wheel from the git checkout it works fine
[17:30:22] <apollo13> hmm no, there seems to be something else missing, the git checkout now has the same error
[17:31:58] <apollo13> /home/florian/.virtualenvs/f234941b484122a5/django/conf/locale/de/LC_MESSAGES/django.po
[17:32:41] <apollo13> okay, command back, datafiles are installed to the venv root, that's the issue, my bash tricked me into a wrong dir before
[17:33:23] <apollo13> I misstyped cdvirtualenv with cdsitepackages at some point which led me to believe that my wheel was functional at some point
[17:34:30] <apollo13> 1d424817 (Adrian Holovaty 2006-10-16 21:50:46 +0000 81) data_files = data_files,
[17:34:42] <apollo13> but we are installing data_files since 2006 and they never end up in the root?
[17:35:29] <dstufft> http://docs.python.org/2/distutils/setupscript.html#installing-additional-files
[17:37:52] <dstufft> it works when you do setup.py install because Django's setup.py monkeypatches distutils to tell it to put datafiles inside the PURELIB directory
[17:38:15] <dstufft> it doesn't work when you install it from a Wheel because Django can't monkeypatch that so it goes to where it should go
[17:39:49] <dstufft> then https://github.com/django/django/blob/1.4.10/setup.py#L7-L43 and https://github.com/django/django/blob/1.4.10/setup.py#L62-L66 can be deleted too
[17:40:30] <qwcode> apollo13, you seen this? https://bitbucket.org/dholth/wheel/issue/80/wheel-does-not-install-data_files-in-site
[17:41:42] <qwcode> apollo13, this is another wheel difference too https://bitbucket.org/dholth/wheel/issue/92/bdist_wheel-makes-absolute-data_files
[17:43:00] <apollo13> http://github.com/django/django/commit/506913cdd85fbe52eb29e62e6884b398f0ef1dc2
[17:44:09] <apollo13> which got me confused now, cause I added the Makefile just for bdist_wheel in the first place, hence I thought I backported wheel stuff to 1.4
[17:44:40] <apollo13> you could just backport https://github.com/django/django/commit/a5becad9094e5c5403b692b9a7b3a6ffaabf64a3
[17:44:50] <jezdez> fwiw, if we're switching to using package_data (we should) then take a look at find_package_data
[17:44:52] <jezdez> https://github.com/django-compressor/django-compressor/blob/master/setup.py#L30-L107
[17:46:13] <jezdez> apollo13: well, include_package_data should just work on newer versions of python
[17:53:05] <dstufft> https://gist.github.com/dstufft/9139344#file-virtualenv-tree-L21-L22 here is data file being installed to root
[18:08:52] <qwcode> dstufft, as for absolute paths, there's what should be, and then there's the concern that bdist_wheel (as setuptools extension) behaves very differently than setuptools
[18:10:02] <dstufft> sudo pip install something -> downloads a Wheel which overrides your /etc/hosts
[18:10:56] <qwcode> dstufft, I mentioned making bdist_wheel fail for absolure paths in the issue description, so I agree, but my concern was more about wheel doing something inconsistent with setuptools, vs security
[18:12:15] <qwcode> dstufft, I'm guessing many people rely on setuptools allowing absolute data_file paths.... for wheel just to stuff those files somewhere else, is odd. better to fail, so people can know to package differently
[18:13:44] <qwcode> I'm guessing daniel just doesn't have the time to respond to that issue. I though it was a big deal : )
[20:29:55] <qwcode> dstufft, on a related note, our Authors files is hard to maintain, because it's not just a simple list of authors from commits. it has alternative names, due to older times, where people were asked to add themselves. thinking it should just be an automated deal from commit names
[20:34:32] <qwcode> daniel says absolute paths "need to be allowed", but not clear what his rationale is