Log file Viewer
#pypa logs for Thursday the 8th of January, 2015
[01:13:21] <prologic> So it's no longer possible to configure the location of pip's cache on disk and to have s shared cache?
[01:32:38] <prologic> this forces us to use a local pypi cache in that case if we want to share a "cache" amongst multiple users
[01:42:52] <prologic> Is there a sensible way to share pip's cache (without installing/using some kind of pypi cache?)
[02:18:11] <dstufft> prologic: nah, we just changed the name to reflect the fact it's a generic ache dir and not just a download cache dir, and set it by default
[06:40:18] <mgedmin> wsanchez, pip freeze > requirements-stable.txt is the thing to take all the installed packages (and their versions)
[06:40:46] <mgedmin> if you create a fresh empty virtualenv and pip install your package into it, you'll get exactly all the dependencies
[12:33:00] <pf_moore> Before I start hacking a new pip subcommand (and having my brain explode because the finder) is there really no way to ask pip "if I say pip install foo, what will you download?" - ignoring dependencies so we don't need to actually download and run setup.py
[12:33:47] <pf_moore> Some questions I commonly ask - what version will I get and will it be a wheel or a sdist
[12:39:17] <pf_moore> I feel the need for "pip query REQs" - displays project name, version, filename, download source. Might give it a go.
[12:39:59] <mgedmin> I missed pip's equivalents of apt-cache show/apt-cache policy a couple of times before
[12:46:37] <dstufft> pf_moore: I thought about doing a --dry-run flag on pip install, but the dependency thing is an issue :(
[12:47:35] <pf_moore> dstufft: Yeah, but I want to decouple it from install - that's got far too much other complexity
[12:48:15] <mgedmin> well, warehouse will store install_requires and extras_require in pypi metadata, right? eventually ;)
[12:48:20] <dstufft> pf_moore: I think it depends on what the question you're attempting to answer is
[12:48:39] <pf_moore> Basically I often find myself wanting to ask "will pip install get me a wheel or a sdist?" If a sdist, I want to do pip wheel first
[12:49:13] <dstufft> pf_moore: that sounds like a pip install --dry-run question to me, because otherwise you're going to be duplicating logic I think?
[12:50:26] <pf_moore> Well, if it produced a report like pip list does rather than the install output crap that I'd have to parse (I want to put this in a utility script)
[12:51:07] <pf_moore> Basically, I'm still trying to find a way to maintain a local wheel cache that doesn't involve doing it manually.
[12:51:18] <dstufft> pf_moore: there's an open issue about doing this in a format that chef and friends can use to see what a pip install would install
[12:51:45] <pf_moore> pip wheel does a lot of it automatically, but doesn't tell me "the project's started uploading wheels now so you can stop"
[12:54:30] <mgedmin> I misunderstood "Skipping virtualenv, due to already being wheel" as "not doing anything at all, ,honest, guv"
[12:54:40] <pf_moore> Basically, we've got pip list and pip show that work on what's installed locally. I want something similar for what's *not* yet installed. And pip search is basically useless because it does a fuzzy search not a name lookup
[12:55:32] <mgedmin> sometimes I want 'pip, what version of foo do I have and is it the latest version of foo on PyPI or should I consider upgrading?'
[12:55:48] <pf_moore> dstufft: maybe - I might try to write that and then see if I no longer care about the rest :-)
[12:56:28] <mgedmin> and sometimes I want 'pip, download the source tarball of the latest foo from pypi into the current working directory because I'm about to build a debian package out of it'
[12:56:53] <mgedmin> --outdated doesn't answer the "which version I currently have" if it's also the latest on pypi
[12:57:26] <[Tritium]> Silly question, isnt the new pypi infrastructure supposed to make it so metadata can be fetched seperate from the package itself?
[12:57:33] <mgedmin> 'pip search foo' almost answers both questions, but it takes a while and produces a bunch of irrelevant matches
[12:57:51] <dstufft> [Tritium]: yes and no. the problem is that for sdists we simply don't have that information
[12:58:07] <dstufft> it's locked inside of a setup.py file that PyPI can't execute for security reasons
[12:58:40] <mgedmin> 'setup.py register' could upload that info while it's uploading long_description etc
[12:58:53] <dstufft> and even if we could execute it, people put conditionals in their setup.py so it might only be valid for the platform we run, or the python we run, or it might be a randomized dependency list and it's only valid for one particular run
[12:59:27] <mgedmin> conditionals in setup.py are a Bad Idea for many reasons -- I know since I use them extensively :)
[13:00:19] <mgedmin> I'll stop as soon as I'm sure the alternative syntax (extras_require={':somethingcomplicated': [...]}) is supported sufficiently well out in the real world
[13:01:02] <mgedmin> the best part is where detox races running setup.py egg_info on all the python versions at the same time, and then parses that egg_info that it (or some other python) wrote
[13:09:29] <bersace> pip 1.5.6 from /home/nova/.virtualenvs/rh2/local/lib/python2.7/site-packages (python 2.7)
[13:09:53] <dstufft> if you're using pip 1.5 you probably need --pre, but pinning is probably the real right answer here
[13:13:44] <mgedmin> ok, if you have a unpinned requirement list and you're using a CI to freeze the versions if they past test
[13:14:02] <pf_moore> dstufft: re pip wheel --lazy, the download happens in requirement_set.prepare_files, which is *way* too messy to pick out a "don't bother downloading existing wheels" codepath
[13:14:15] <mgedmin> how about adding 'thispackage >= 0.7.3.novapost1' to your requirements.txt, so pip will be forced to consider the "prerelease" version?
[13:14:35] <mgedmin> uh, I should maybe double-check if pip 1.5 will do that or if it'll fail with a "no released version found matching requirement ..."
[13:14:58] <pf_moore> dstufft: You made me read the requirements code again, now my ears are bleeding.
[13:15:43] <pf_moore> np, I should know better - "here be dragons", or is it "abandon all hope, ye who enter"?
[13:17:54] <xafer> fwiw, I've some waiting PR around prepare_files that try to simplify it (but small steps)
[17:46:32] <dstufft> AlexMeng: if the person who currently owns it wants to transfer they just need to add the new person under roles
[18:27:54] <wsanchez> mgedmin: eggdeps is way more useful because I can see why things are in the list. pip freeze just lists everything.
[23:41:13] <gnudestallman> If I use setuptools option, include_package_data = True, how do I access the data when it is installed?