Log file Viewer

[06:13:24] <stor> hi, i have a pip-related question. my setup.py has "foo" in install_requires, i have a modified version of it in ../foo. how can i make pip install my version instead of downloading it? i tried adding "../foo" in requirements.txt and using "pip install -e . -r requirements.txt" but that doesn't seem to work, still uses the cached wheel

[06:15:03] <stor> removing it from setup.py seems to help

[06:17:42] <stor> i'm not even sure what's the recommended way to deal with using a modified version of package normally available from pypa

[06:45:23] <stor> alright, for the record my latest solution is: changed the version number in ../foo/setup.py to "1.0-edited" and use "foo==1.0-edited" in my setup.py and have "../foo" in requirements.txt

[09:42:04] <ThiefMaster> was the issue tracker for setuptools etc on bitbucket disabled on purpose?

[14:53:23] <ngoldbaum> ThiefMaster: https://github.com/pypa/setuptools/issues ?

[14:53:48] <ThiefMaster> oh, you moved to github - nice

[20:32:29] <gsnedders> I presume there's no way to get reverse dependencies currently from PyPI? seems to be a todo for warehouse?

[20:39:23] <ronny> gsnedders: is there a issue about it on warehouse (this seems expensive)

[20:41:18] <gsnedders> ronny: there's a TODO in the frontend currently

[20:43:44] <gsnedders> ronny: I presume the intention is to store dependencies in the DB (which I believe cheeseshop does currently?) in which case given a sensible DB schema it shouldn't be particularly expensive, no?

[20:58:23] <dstufft> gsnedders: it's in the schema, but most projects don't expose that info when they upload

[21:05:12] <gsnedders> dstufft: how does pip deal with this, then? when it runs setup.py of each?

[21:07:21] <dstufft> gsnedders: yea, it runs setup.py egg_info and then inspects the files produced

[21:07:40] <dstufft> PyPI doesn't try to read inside of the file much, the upload protocol sends that data alongside things

[21:07:54] <dstufft> if you use twine _and_ you upload wheels you'll sort of get that info

[21:08:06] <dstufft> but it's got caveats

[21:12:38] <gsnedders> dstufft: right, so /that/ needs solved before we can really start doing this?

[21:12:56] <dstufft> gsnedders: I mean, we can do it with the data we have available, but in general we don't have that data available

[21:13:43] <dstufft> gsnedders: there's a more fundamental question too, a py2 vs py3 wheel can have completely different dependencies, which set do we consider to be the canonical? Or do we union them? or something more advanced

[21:14:02] <dstufft> (the same extends out to anything that you can stick in a filename for wheel)

[21:14:08] <ronny> oO

[21:14:27] <ronny> why not simly decalre that dependencies are per artifact

[21:14:41] <gsnedders> dstufft: and there's the fun of dependencies depending on markers too

[21:14:43] <dstufft> well they are for pip and such

[21:14:44] <ronny> then different implementation tags for wheels create different artifacts

[21:14:58] <ronny> dstufft: for warehouse it isnt?

[21:15:06] <dstufft> Not for PyPI no

[21:15:11] <dstufft> the DB schema doesn't allow it atm

[21:15:44] <dstufft> I mean, techincally _all_ metadata is per artifact, but most of it is the same on all artifacts of a particular version

[21:16:00] <dstufft> so PyPI stores most metadata once per (project, version)

[21:16:56] <gsnedders> dstufft: basically my use-case here is "I want to make a breaking change to my package, and I want to give dependants a warning to make sure they aren't unconditionally allowing future releases"

[21:17:05] <gsnedders> obviously here I have a bias towards more used packages

[21:17:17] <dstufft> gsnedders: yea, we don't have a great way to solve that currently :/

[21:17:26] <dstufft> besides code level deprecation warnings

[21:17:49] <gsnedders> obviously things which vendor it in don't have that problem, or when packaged separately with correct versions…

[21:18:29] <dstufft> gsnedders: are we using the API in a way that'd break it?

[21:18:32] <gsnedders> and for some reason I don't trust downstream places to constrain versions correctly

[21:18:37] <gsnedders> dstufft: I haven't looked, but I think so.

[21:18:45] <gsnedders> dstufft: will look later

[21:18:47] <dstufft> womp womp

[21:19:04] <gsnedders> dstufft: I can throw up a PR that will make it work with both old and new APIs

[21:19:36] <dstufft> https://github.com/pypa/pip/blob/master/pip/index.py#L693-L697 is about it fwiw, with https://github.com/pypa/pip/blob/master/pip/index.py#L811-L831

[21:19:49] <gsnedders> (basically, next release of html5lib is gonna have everything needed for 1.0 and API stability)

[21:20:06] <dstufft> gsnedders: Awe, no more 0.999999999? :]

[21:20:19] <gsnedders> dstufft: I expect we'll have at least one or two more pre-1.0 releases

[21:20:26] <gsnedders> dstufft: but this should be it with API breakage

[21:20:41] <dstufft> AsymptoteVer

[21:20:54] <gsnedders> dstufft: there might be some breakage in some things doing crazy things when I make a clear distinction between private and public APIs, which really isn't clear atm

[21:21:12] <dstufft> gsnedders: cool, well we bundle/pin exactly for this reason :]

[21:21:14] <gsnedders> dstufft: but in principle anything that's intended to be public will be stable from the next releas

[21:21:22] <dstufft> and I convinced Debian to not really unbundle

[21:21:36] <dstufft> they just re-bundle based off of their copy of html5lib (and such)

[21:21:42] <dstufft> and run tests I think

[21:21:48] <dstufft> so they should catch it too!

[21:21:53] <gsnedders> dstufft: hell, FWIW, I'm pretty sure what I have in mind for 2.0 won't need changes for pip (or most things)

[21:22:01] <dstufft> gsnedders: awesome :]

[21:22:12] <dstufft> Gotta go cook dinner on the grill, bbiab

[21:22:13] <gsnedders> dstufft: basically these are gonna be the last changes that affect most people

[21:22:44] <gsnedders> dstufft: the big breakage is removing the encoding arg and replacing it with about five, where the only one most people want is transport_encoding