Log file Viewer
#pypa-dev logs for Thursday the 3rd of September, 2015
[12:31:01] <dstufft> xafer: It'll be a few months, but I wanted to get the code changes for PEP 470 into pip which require a version bump to 8
[12:33:29] <dstufft> it's unlikely I was going to be cutting a major release between then and now anyways, I'm mostly focused on warehouse ATM
[12:37:44] <dstufft> xafer: makes sense, I have to run to the doctors office, if you make a pip 8 milestone and add anything you'd like to see in it to that, I can make sure we don't cut a pip 8 release without them (or without explicitly deciding to move forward without them)
[18:28:22] <ronny> dstufft: thats a mallsie mess up then ^^ its impossible to have scripts pull in a new setuptools version with pip install --target
[18:29:09] <ronny> dstufft: im currently creating a replacement for ez_setup/install_requires/test_requires that uses the ini file a script and pip install --target .eggs/site-pacakges
[18:29:38] <dstufft> we won't even try to execute the setup.py unless setuptools is already installed
[18:30:40] <ronny> dstufft: but how do i prevent the injection, i cant propperly override the import paths after the facts because setuptools goes into distutils as well (i suppose i can throw away all related modules)
[18:31:04] <ronny> dstufft: is it enough to simply remove pkg_resources, setuptools and distutils from sys.modules?
[18:32:31] <dstufft> ronny: to answer your first question, right now you don't prevent the injection. If we were going to go down that road there'd need to be a discussion if wew ant to make it possible to disable the injection or not, as far as what you'd need to delete from sys.modules.. I Don't know. I've never attempted it
[18:53:59] <ronny> dstufft: i just figured, i could actually always run a python -S when i detect setuptools
[19:16:05] <ronny> dstufft: would it be acceptable for pip to provide a distribution class which replaces fetch_build_egg/fetch_build_eggs?
[19:21:56] <ronny> hmm, the interdependent limitations in pip, setuptools and python packaging in general are quit a pain ^^
[20:58:35] <dstufft> I'm not sure I like splitting on the + instead of just sticking the whole "git+ssh" into the protocol list, but I don't feel strongly about it
[21:03:19] <xafer> but then you'd have to put git/svn/hg/bzr+ssh/https additionnal protocol at least ?
[21:21:34] <xafer> apparently from https://github.com/pypa/pip/issues/754 I see you can make crazy things with hg :o
[21:27:52] <xafer> For https://github.com/pypa/pip/pull/2812 where there is no changelog, do you usually add the changelog in the merge commit ? or create an additionnal PR ? or directly commit ?
[21:28:27] <dstufft> I normally do a git diff before I release and look for anything important that didn't get called out
[21:34:07] <ErikRose> jezdez: Parsing hashes out of the reqs.txt file works. :-D Now to make it do something...
[21:42:28] <ErikRose> jezdez: So far, so good: https://github.com/pypa/pip/compare/develop...erikrose:hashing?expand=1
[21:47:25] <dstufft> ErikRose: not that I think it's wrong, but why not support the #sha256=...&md5=... etc that requirements.txt already uses for egg name and sub directory?
[21:48:36] <ErikRose> dstufft: There's quite a bit of back-and-forth in the history (and present) of https://github.com/erikrose/peep/wiki/PipHashing, but the reason I can remember off the top of my head is that it makes the command-line interface and the reqs.txt one the same.
[21:49:11] <dstufft> ErikRose: you can't pass --sha256 on the CLI can you? there's no interface for saying that this particular flag is only for X project?
[21:49:58] <ErikRose> I'd follow the precedent of the find command: pip install SomePackage==1.2.3 --sha256=abcde... OtherPackage==4.5.6 --sha256=12345...
[21:50:15] <ErikRose> Multiple valid hashes can be specified straightforwardly by repeating the option.
[21:50:40] <ErikRose> And it's spelled the same whether the package specifier is a distro name or a URL.
[21:51:08] <ErikRose> I think we had really good reasons for it, but those are the reasons I can remember atm. :-)
[21:53:32] <dstufft> yea adjusting which particular hashes is easy given it supports multiple hashes out of the gate
[21:55:01] <dstufft> ErikRose: fwiw I plan on switching things to click, I'm not sure if click supports multiple ordered things like that though. Something to consider to see if one syntax will lock us into a particular parsing library or not
[21:57:36] <dstufft> once we kill pypi legacy (or maybe before if I feel like touching pypi legacy's code base) we'll kill the md5 hashes completely off PyPI too
[21:58:44] <ErikRose> I was so glad somebody did the backward-incompatible patch to support multi-line backslashy reqs.txt lines.
[21:59:35] <ErikRose> Plus this way you can comment them: "this one's for the wheel" "this is for the windows binary" "the sdist"
[22:01:38] <ErikRose> Here's the way I'm leaning atm. I'm very open to argument; I'm not entirely satisfied:
[22:01:42] <ErikRose> "If any hashes are specified, --no-deps and --require-hashes turn on. This is a little surprising, but it fails safe: otherwise, dependencies of hashes packages will install without being hash-verified. If you want to be unsafe, you should say --ignore-hashes explicitly. Or have a --no-require-hashes."
[22:02:49] <dstufft> I'm not sure if --no-deps is the exactly right thing, but I agree with the sentiment
[22:03:18] <ErikRose> The only thing that makes me waver toward including --ignore-hashes is a future in which people complain they can't do something goofy with some library's reqs.txt file because they're, say, including it from their unhashed one, so the lib maintainer instead rips out all the hashes.
[22:04:29] <ErikRose> ^not that I mean for library authors to start hash-pinning things. I think that would be an antipattern.
[22:04:59] <dstufft> I'm not sure exactly what --no-deps is going to mean as we migrate towards a real resolver and paying attention to what's already installed and such
[22:05:24] <dstufft> I think it's fine to use it right now, and just add a comment about that though
[22:05:51] <ErikRose> Yes, the what's-already-installed bit is pretty uncharted territory as far as peep's concerned.
[22:06:27] <ErikRose> but then people started wanting to reuse deployment venvs, so I made it trust packages that were already installed.
[22:06:29] <dstufft> in particular though, if "foo" depends on "bar" and "frob", you still want install to fail if requirements.txt only contains "foo" and "bar"
[22:07:05] <dstufft> so you still want to process dependency information, you just want to refuse to install anything that doesn't have an associated hash with it
[22:07:31] <ErikRose> That would be a better behavior than right now, in which you get an importerror at runtime.
[22:08:13] <dstufft> hopefully you have a good therapist for once you're done plumbing the depths of pip
[22:09:58] <dstufft> ErikRose: you'll also want to do something about --egg, either warn about it in the docs, or bomb out if someone passes --egg when "secure mode" is on
[22:12:10] <dstufft> ErikRose: I guess you'll have to stash some extra data for pip freeze --hash, since we don't keep the original dist around to hash it when we do the install
[22:13:13] <ErikRose> Next, the fun part: actual hash checking amidst the forest of legacy ifs. Oooo, booga booga booga.
[22:13:13] <ErikRose> btw, click might not be totally hostile to interleaved options: http://click.pocoo.org/5/complex/#interleaved-commands
[22:14:58] <dstufft> ErikRose: it basically means "break tons of pip features because we stop telling setuptools not to install dependencies and instead just let setuptools do a bunch of crap"