Log file Viewer
#pypa logs for Thursday the 3rd of July, 2014
[00:14:56] <dstufft> nanonyme: the answer to your question, is pip doesn't require anything to install wheels, wheels are very simple to install, they are basically unzip + move files around (plus a few other things like compiling pycs and generating script wrappers, but overall basically uinpack + copy)
[00:15:31] <dstufft> to _create_ wheels, with something like ``pip wheel``, you need to ``pip install wheel`` because creating wheels is harder and requires hooking into setuptools (at the moment, that's not an actual requirement of the format, jsut of the wheel lib)
[00:16:18] <nanonyme> dstufft, I thought wheel was some library that you needed to have installed to begin with
[00:16:57] <dstufft> nanonyme: nope! It's a format, and anything can install it, techincally you can even install a very basic one with nothing but ``unzip`` and ``cp``
[00:17:14] <dstufft> there is also a wheel library, but it really only exists in order to make ``setup.py bdist_wheel`` work
[00:17:34] <dstufft> you can create wheels without it no problem though, there's just no tooling to do it right now
[00:19:01] <dstufft> you need it installed for ``pip wheel`` to work, because all ``pip wheel`` really does is ``setup.py bdist_wheel``
[00:19:41] <dstufft> pip can install from wheels without anything else installed, because installing is simple
[00:21:24] <dstufft> pip 1.4 uinderstands wheel, but doesn't install it by default (and it has some bugs, it was considered experimental), pip 1.5.x installs wheels by default if they are available
[00:23:18] <nanonyme> https://packages.debian.org/search?keywords=python-pip&searchon=names&suite=testing§ion=all Debian packaging of it is just *so* odd
[00:24:38] <dstufft> normally my complaint about linux is they have 1.0 packaged still in debian stable :)
[00:25:13] <dstufft> that's actually nothing to do with pip itself, it contains a pip-1.5.6-blah-blah.whl
[00:25:46] <nanonyme> I'm fortunate enough to get to have decided that the servers I write automatic Django project deployment to run Debian testing
[00:28:30] <nanonyme> But anyway, so with Windows you get pip bootstrapped so you will actually have the newest if I'm right
[00:30:05] <nanonyme> Ah, was wondering why the sucker of a lxml wanted compiling on Windows. Looks like lxml only has Python3.2 support, no 3.4
[00:31:19] <nanonyme> dstufft, btw, pip self-upgrades on Windows are fairly broken. Dunno if anyone's complained
[00:35:31] <nanonyme> Basically what you do to avoid Windows being an ass is you rename the exe to a temp name instead of deleting it and tell Windows to delete it on next reboot
[00:36:09] <nanonyme> (if I've understood correctly; I only have surface-level touch with the hacks involved)
[00:37:45] <dstufft> so I'm unlikely to fix it anytime soon D: but if someone did in a way that pf_moore (our resident windows dev!) said was OK we'd likely merge it :)
[00:41:40] <dstufft> and i'm fine with that :) I don't use Windows so I can't speak to what feels natural there
[00:42:23] <nanonyme> Anyway, lxml installed really nicely from a wheel with pip here without wheel the package being installed using pip 1.5.4
[00:44:12] <dstufft> there is a function that tries to make them relocatable, but idk how well it works
[00:45:36] <nanonyme> We use shared virtualenvs a lot where I work and while we most of the time put them in same place, there's every now and then demand for eg different partition
[00:45:55] <dstufft> generally the problem with relocating virtualenvs is stuff with hardcoded paths, the major place being shebang lines
[00:46:19] <dstufft> rewriting shebang lines gets you most of the way there, but sometimes a path gets hardcoded soemwhere else
[00:49:45] <nanonyme> Anyway, thanks to all the related parties who have been dealing with wheel. I *really* appreciate being able to finally migrate fully to pip
[00:50:50] <dstufft> I'm glad it's useful :D That was Daniels baby, and hopefully we'll expand upon it more in the future to include some things that people were missing still to be able to actually use them
[00:53:58] <nanonyme> The only thing I think is sad that there was refusal on backporting the pip bootstrapping into Python2.7
[00:55:03] <nanonyme> Oh? Back when I read the original bug, the attitude seemed to be that core devs hate Python2 users and want them to migrate to Python3 already :P
[00:55:43] <dstufft> Mostly the situation is "what can we do to make it easier for people to migrate to py3"
[00:56:21] <dstufft> for projects which don't want to have dependencies because bootstrapping pip is hard
[00:57:09] <nanonyme> Well, the thing is, Python2 for Windows comes with easy_install but no pip. Hence we still get *new* easy_install users. I think this is sad
[01:01:35] <nanonyme> But yeah, we're still at 2.6.something. I should really take the time sooner or later to push for 2.7.something so eventual migration to 3 won't be so painful
[01:03:01] <nanonyme> Painful steps, more like... It's about installing a different version of Python to potentially hundreds of machines
[01:04:45] <nanonyme> If there wasn't a lot of manual work involved, I'd probably have migrated already. It's not that rarely that we hit bugs in Python stdlib that are fixed already in bugfix releases
[01:06:09] <nanonyme> It is rather unfortunate in the case of eg urllib since you can't even update it
[01:07:24] <nanonyme> (or rather, such that all stdlib packages would live in PyPI and you could override them with newer versions eg from a virtualenv)
[01:09:22] <dstufft> and you're better off shipping a good packaging tool, and a set of preinstalled things
[01:10:46] <nanonyme> I guess part of Python stdlib's problem is the idea that there's a contract that if something is put to stdlib once, its API must never change
[01:12:47] <dstufft> but also is there really any reason for the release schedule of a language, an xmlrpc library, and a IDE to have their release schedules sychronized
[01:14:11] <nanonyme> But I guess Python syntax changes seldom enough that that's not often a problem
[01:15:57] <nanonyme> Yes. I was just meaning that it very much affects stdlib and what works with what. Though I guess backwards-compatible syntax changes are an even less likely thing to happen than backwards-incompatible API changes in stdlib...
[01:18:34] <nanonyme> Anyway, would probably help considerably if I just installed eg requests to the virtualenv and ported all code from stdlib HTTP modules to it instead. That's at least updatable
[11:16:28] <nanonyme> dstufft, btw, when I had a wisdom tooth removed, my dentist told me to eat a lot of ice cream to help with the pain. Just FWIW
[14:36:14] <nanonyme> Btw, can I put wheels inside a Python zip? (ie those zip files that have a __main__.py and are runnable)
[14:36:44] <nanonyme> Imo that'd be pretty neat, could just junk compiled dependencies in the zip, offer it to someone and have them run it with no installation
[14:39:04] <nanonyme> Or hmm, maybe not necessarily need to be even that. Maybe rather a pip plugin that would automatically construct a runnable zip bundle with all the deps compiled
[15:25:50] <[Tritium]> I am curious if the PyPA has a stance on non-packaging tools (test suits, linters, and the like) using setup.cfg for their configuration
[15:41:44] <radix> in clojure there is "project.clj", and testing tools and linters are usually plugins to lein, so it's more natural there.
[15:44:20] <[Tritium]> Well, its happening as it stands... flake8, nose, pytest... they look in setup.cfg already. I am basicly asking if this is something that is encouraged or something that should be moved away from in the opinion of the pypa
[15:48:02] <[Tritium]> I actually have never used the file for anything related to setuptools/distutils... I prefer to do that in code...
[17:04:09] <dstufft> mitsuhiko: now that I've got that gc thing sorted, I'll take a look at your test failures once I get back from lunch
[17:07:36] <nanonyme> So, yeah. Are there best-practices for bundling precompiled dependency packages?
[23:58:58] <dstufft> mitsuhiko: is because your target dir is in the scratch dir, and when os.removedirs() is called on $scratch_dir/target/simpledist/__pycache__, that python recurses upwards deleting __pycache__, then simpledist, then target, then $scratch_dir