Log file Viewer

[05:50:33] <pmxbot> jaraco pushed 3 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :

[05:50:33] <pmxbot> Created new branch fix-type-error-skip-reason

[05:50:33] <pmxbot> Fix TypeError for pytest.skip()

[05:50:33] <pmxbot> Merged in toabctl/setuptools/fix-type-error-skip-reason (pull request #127)

[05:50:34] <pmxbot> jaraco pushed 1 commit to setuptools (https://bitbucket.org/pypa/setuptools/) :

[05:50:34] <pmxbot> Merged in toabctl/setuptools/fix-type-error-skip-reason (pull request #127)

[12:53:17] <abadger1999> hey ansible sprinters, I'm off to a slow start this morning -- will be up to the room shortly.

[12:54:27] <dstufft> jaraco: btw, I have the devpi thing fixed in packaging 15.1 and pulled into pip develop branch

[12:54:49] <dstufft> jaraco: I'll release later today, setuptools might want to pull it in and release too

[12:55:01] <jaraco> dstufft: sounds good. I'll do that now.

[12:57:06] <ronny> btw, why is packaging still vendored?

[12:59:27] <dstufft> ronny: pip (or setuptools) depending on stuff doesn't work very well. It would probably work OK in setuptools if you ignored ``easy_install`` and only ever interacted with setuptools via pip, but pip is strictly no real dependencies (optional dependencies are OK, or dependencies to interact with a specific package, but pip itself can't)

[13:01:42] <ronny> dstufft: can we get a wheel bundle format, where on can put wheels that are required for isntallation into the wheel, and for one level of indirection it would unpack>

[13:02:35] <pmxbot> jaraco pushed 2 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :

[13:02:35] <pmxbot> Bump packaging version to 15.1

[13:02:35] <pmxbot> Update changelog

[13:03:05] <dstufft> ronny: nothing is required to install a wheel besides pip itself (at least currently, in the future maybe with PEP 426 extensions), even then, you can install some wheels with nothing more than the ``unzip`` command

[13:03:42] <ronny> dstufft: i see

[13:04:03] <dstufft> jaraco: lol, got confused for a minute with setuptools 15.1 vs packaging 15.1

[13:04:17] <jaraco> Yep. Funny coincidence.

[13:06:29] <jaraco> ronny, in https://bitbucket.org/pypa/setuptools/issue/229 I'm working on a technique whereby setuptools could have dependencies, but I've had trouble with it (mostly with the tests that were shelling out, which may now be gone).

[13:06:35] <ronny> dstufft: so bootstraping is unsolved atm?

[13:07:32] <ronny> jaraco: btw, got any oppinion on putting unpacked wheels into a sdists .egg folder?

[13:07:55] <dstufft> ronny: we can bootstrap things just fine, it's more about how that influences your environment

[13:08:32] <ronny> dstufft: if bootstraping was fine, deps wouldnt be an issue ^^

[13:08:46] <dstufft> ronny: for instance, pip depends on requests (in particular, a fairly recent version of requests, I think 2.5+), what if your app uses an earlier incompatible version? Now you have to decide between having a working package manager and being forced to update your app in order to get a new version of pip

[13:08:55] <jaraco> ronny: that sounds like a bad idea - that means that modules and python packages will be added implicitly to sys.path as part of adding that egg.

[13:09:18] <dstufft> pip is incidental to the working of your application, but if pip has dependencies then it's suddenly enforcing versions against, well basically every single python environment

[13:09:24] <ronny> jaraco: whops, misstyped. i meant the .eggs folder

[13:10:26] <dstufft> Additionally, what happens if you end up doing something like ``pip install 'requests<1.0'`` and downgrade your requests? Now your pip is broken and you don't have a good way to fix it besides manually going in and deleting requests and manually installing the right version

[13:10:44] <ronny> dstufft: to me thats an indication that single version installs are lacking,

[13:10:58] <jaraco> ronny, unzipped wheels fall prey to the same issues I raised here - https://bitbucket.org/pypa/setuptools/issue/371/setuptools-and-state-of-pep-376#comment-17391764

[13:11:02] <dstufft> ronny: multiversion installs have their own problems *shrug*

[13:11:06] <ronny> and one either needs an installer that is external to the environment or multi version installs

[13:12:10] <dstufft> ronny: how do you have an isntaller that's external to the only Python that's on your system?

[13:12:30] <dstufft> ronny: this isn't really an easily solvable problem, for instance, even Debian statically links dpkg's dependencies

[13:12:45] <dstufft> for basically the same reason

[13:13:02] <dstufft> and C libraries have multi version installs

[13:13:37] <dstufft> originally pip dependened on setuptools to function at all, and it was terrible

[13:14:06] <dstufft> things broke regularly (not setuptools itself breaking, just the interaction of pip having a dependency)

[13:14:33] <dstufft> since we started bundling pkg_resources for pip's internal uses we eliminated that class of problem

[13:14:45] <dstufft> installers are just special cases *shrug*

[13:15:19] <dstufft> I think setuptools the build tool having dependencies would work fine, I think setuptools the installer having dependencies will end up painful tbh

[13:17:55] <dstufft> actually, I know that Barry Warsaw had problems with setuptools + pex on his Debian machine because Debian de-vendored packaging from inside of setuptools

[13:18:10] <pmxbot> jaraco pushed 2 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :

[13:18:10] <pmxbot> Added tag 15.1 for changeset 10fde952613b

[13:18:10] <pmxbot> Bumped to 15.2 in preparation for next release.

[13:20:00] <dstufft> and we get regularly issues from people who install pip from their system package mananger on Debuntu (which debundles the things that pip bundles) which are directly caused by the fact that they debundled

[13:21:20] <dstufft> if I recall, debuntu is planning on (or has already) fixed that, by munging sys.path to ensure that special copies of those dependencies get added to the sys.path for pip (not regularly installed copies, copies that exist only for pip but which are built from the regular Debian packages for those dependnecies)

[13:24:57] <ronny> dstufft: what if there where system wide/per user repos of unpacked wheels and scripts/virtualenvs could pick and coose from those (having a path mechanism thats not as exensive as sys.path addition)

[13:26:09] <ronny> (expensive)

[13:28:04] <ronny> dstufft: then pip could bascially always use the exact right versions of dependencies even if normal scripts used the normal workingset

[13:28:18] <dstufft> ronny: dunno, maybe. It still doesn't solve the "I uninstalled the version of requests that pip depends on and now my package manager is broken and the only way to fix it is to go download a wheel and manually unpack it and try to move it into the right locations"

[13:29:22] <ronny> dstufft: uninstall would only remove it from the default workingset, scripts like pip would request a tailored workingset, and gc of the wheel repo would be distinct from pip uninstall in a env

[13:30:46] <ronny> and you could even do some more, like nsure that even if installed in a env, pip is only importable when the workignset fits to begin with

[13:31:19] <ronny> and pip would always stay runnable since being installed would prevent gc of the tailored depencencies

[13:32:04] <dstufft> ronny: maybe, I haven't spent much time thinking about something like that. Would need someone to explore it and try to break it

[13:32:38] <ronny> dstufft: i already found someone to explore it with, but it needs time

[13:33:44] <ronny> the rough target is pip being aware of conda, and pip being able to use wheel repos stored per user/system wide

[13:42:55] <xafer> hello dstufft, since you released a new packaging version, it reminded me of https://github.com/pypa/pip/issues/2619#issuecomment-87845580

[13:48:50] <ronny> xafer: a new pip release is already sheduled

[13:53:45] <xafer> ronny: it looks like an issue with the packaging module

[13:55:09] <ronny> xafer: it is, and since pip vendors it a new pip release has been sheduled

[13:59:27] <xafer> well the issue (?) seems to be still present in the latest packaging so a pip release wont help :-p

[16:57:51] <trishank> hello everyone!

[17:01:40] <trishank> the good news is that i think all the easy issues on warehouse have been taken care of

[17:02:03] <trishank> medium issues are next

[17:02:17] <trishank> unfortunately, i must get back to an impending paper deadline

[17:02:27] <trishank> however, i will try to contribute to warehouse whenever i find some downtime

[17:02:41] <trishank> thanks, and see you later!

[20:53:36] <iElectric> dstufft: hmm

[20:53:49] <iElectric> we should be moving queries to the model methods

[20:53:56] <iElectric> so they can be reused later

[23:33:11] <lifeless> whee lots of peoples

[23:33:34] <lifeless> has anyone claimed any of the new issues post-wheel-autobuild? If not I'll get onto them after lunch