Log file Viewer
#pypa logs for Saturday the 28th of December, 2019
[01:17:33] <toad_polo> It's annoyingly complicated, which was why it was excluded in the first place. The solution is simple enough, just getting setuptools to do it is a bit annoying.
[01:28:51] <energizer> toad_polo: the closest thing i can find to anybody having done that part is https://github.com/pypa/pip/issues/6950. is that the api that a proof-of-concept implementation should satisfy?
[09:34:35] <tos9> IMO yeah fine a build_editable function but not jamming it back into how setuptools works
[09:39:21] <energizer> tos9: the other sorta-obvious way would be putting a symlink into site-packages
[09:41:11] <energizer> i'm not clear on the history as to why setuptools uses egg-link instead of doing that
[10:11:21] <tos9> energizer: I think the API should say "you handle it" and let the backend implement it how it feels like, but then provide a default implementation that does it in some encapsulated way
[10:13:12] <energizer> tos9: i could have multiple editable packages installed, and they'd each be editable in their own way; that seems perhaps overly flexible
[10:17:39] <tos9> maybe. do either flit or poetry have their own reimplementation of editable installs already
[12:29:21] <nedbat> when using declarative setup.cfg, why can't i use "file:" for "[options] install_requires"?
[17:13:18] <dtux> i have a project-scoped API token on PyPI that has never been used. When i try to delete it, it asks for my password then tells me its wrong (it's the same one my browser autofills to log into the site, tho, so i'm pretty sure it's right). this sound familiar to anyone?
[20:34:42] <toad_polo> nedbat: `file` is not a generic directive, it's only applicable for certain fields.
[20:35:06] <nedbat> toad_polo: is there a reason why? It would be very useful to have it for install_requires
[20:35:43] <toad_polo> The real reason is probably somewhere between "we don't want to write our own generic DSL" and "ini files are trash"
[20:36:05] <toad_polo> It seems like it would encourage people to put `requirements.txt` there, which is definitely not something we want to encourage.
[20:37:10] <toad_polo> If you have some compelling reason for separating your installs into a file, you can open an issue on the setuptools tracker, we've added `file:` support for fields fairly recently, it's not terribly difficult.
[20:38:00] <toad_polo> nedbat: Here's the list of supported types / directives in `setup.cfg`: https://setuptools.readthedocs.io/en/latest/setuptools.html#metadata
[20:39:06] <nedbat> toad_polo: i guess i would have expected "file:" "attr:" etc to be handled deeper down so that it wouldn't have to be added specifically to certain directives, but these black boxes are always mysterious.
[20:39:26] <nedbat> toad_polo: I have a requirements/base.in file that is used as part of pip-compile, and its contents should be install_requires.
[20:40:08] <toad_polo> People always want to combine those two things, but the dependency should almost always go the other way.
[20:40:29] <toad_polo> `requirements.txt` is basically a kinda-crappy lock file, which should be generated from `install_requires`, never the other way around.
[20:40:41] <nedbat> toad_polo: base.in gets pinned for my library's test suites, but i don't want pins in my distributions.
[20:41:48] <toad_polo> nedbat: The way I'd do it is to have `install_requires` be the source of truth for your application or library's "logical requirements", then you can use `pip-compile` or something to generate a `constraints.txt`
[20:42:49] <toad_polo> For my test suites I also occasionally have a `requirements-dev.txt` or something that has `install_requires`-equivalent information (loose, logical pins), and a corresponding constraints file generated from that.
[20:42:58] <nedbat> toad_polo: so i have a choice: manually copy setup.cfg-install-requires into a base.in, or the other way around.
[20:44:01] <toad_polo> nedbat: i don't really understand that, why can't you do `pip compile` on your application and have the `install_requires` be the source of truth, dropping `base.in` entirely?
[20:46:12] <toad_polo> There's a pretty simple hack to work around that, though, which is to have a requirements file that just contains `.`
[20:48:14] <toad_polo> Maybe there's a better one, I dunno. It's super hard to pin down indirect dependencies, I've been fighting with that a lot when trying to develop something to pin my test dependencies to avoid all the random failures I get on unrelated prs when something deep in the stack changes or starts throwing a warning.
[20:49:17] <nedbat> toad_polo: I'm not sure why the pypa developers would have an opinion about whether the install_requires list is literally in setup.cfg, or is sourced from somewhere else?
[20:49:39] <toad_polo> nedbat: It doesn't really matter. You can certainly just read it in in `setup.py`.
[20:50:02] <nedbat> toad_polo: yes, but i was really enjoying have no real code in my setup.py, and I got *really* close.
[20:50:19] <toad_polo> But the only people I've seen who try to do this are people who think that it's a good idea to use `requirements.txt` as the source of truth.
[20:51:26] <toad_polo> So if 99% of people are going to use this feature to implement an anti-pattern and the remaining 1% have a reasonable workaround (using `setup.py`), I think it's worth it to nudge people in the right direction.
[20:52:20] <toad_polo> nedbat: I mean it's totally reasonable to have an unusual usage pattern. That's why I'm in favor of keeping `setup.py` around in general - it gives a lot of flexibility to people who have unusual requirements.
[20:53:26] <nedbat> toad_polo: hmm, putting "." in base.in make pip-compile add file:////etc/project/etc to the base.txt file... :(
[20:53:29] <toad_polo> Which is why I'd like to migrate to a world where we continue to add support for something like 99% of all workflows and leave the long tail of weird quirks.
[20:54:19] <toad_polo> nedbat: Yeah, I figure you'd want to remove that line anyway, since you're really only trying to install all the dependencies of `.`.
[20:54:49] <toad_polo> But yeah that does mean you're using `sed`, at which point you might want to just use `setup.py`, which will undoubtedly be more readable.
[20:55:10] <nedbat> toad_polo: or I could convince the pypa devs to add support for install_requires = file: :)
[20:55:53] <toad_polo> nedbat: Or convince the `pip-tools` devs to add support for compiling an arbitrary project not just a `requirements.txt`.
[20:57:07] <toad_polo> Though one useful thing that will be coming up if any of us have time to actually do it is that we'll start including the dependency metadata in sdists when it's specified in `setup.cfg`, which will be very useful.
[20:57:12] <nedbat> toad_polo: we have a complex pip-tools arrangement already: https://github.com/edx/edx-platform/tree/master/requirements/edx
[20:59:52] <toad_polo> nedbat: Heh, you know this guy is a committer on setuptools? https://github.com/jmbowman
[21:00:18] <nedbat> to be fair, I have not asked him about the thing that got me started down the file: path.
[21:02:26] <toad_polo> I am very suspicious of this mainly because it encourages an anti-pattern. I understand that it does seem like a very useful solution, though it really seems like this is an issue with a limitation of `pip-compile` more than anything else.
[21:02:43] <toad_polo> And also more of an issue with "there's no reasonable standard lock file in Python packaging"
[21:03:42] <toad_polo> It would be much better if `pip-compile` could just compile a given package's dependencies directly (particularly if you can give it extras0.
[21:04:38] <toad_polo> Then your complicated pip compile requirements could be different extras dependnecies rather than separate requirements files.
[21:05:46] <toad_polo> Though I dunno, I don't deploy many applications. It may be that these long and complicated dependencies are much more common in application development and we would be enabling better workflows as much as we were encouraging bad ones.
[21:08:34] <nedbat> toad_polo: part of me just looks at it as smoothing out idiosyncracies. If a config file can read property X from a file, why can't it read any property from a file?