Log file Viewer

[14:36:15] <dude-x> awscli has hit 100 with version 1.16.100

[16:00:50] <ngoldbaum> njs, toad_polo, dstufft: so one annoying thing about using the existence of pyproject.toml to signal that i want to opt-in to PEP 517/518 is that black uses it for project-specific configuration. That's the only reason I have it in my repo...

[16:01:16] <ngoldbaum> https://github.com/ambv/black#pyprojecttoml

[16:01:44] <toad_polo> ngoldbaum: Yes, that was taken into account when the decision was made.

[16:01:46] <dstufft> ngoldbaum: I'm pretty sure long term PEP 517/518 are going to be the *only* code path pip has, so projects will need to figure out how to cope with them sooner or later

[16:02:27] <dstufft> so it acts as a bit of a forcing function here, to get folks to come to us with use cases where 517/518 aren't currently able to support them, before we start killing it

[16:03:23] <dstufft> ngoldbaum: in the mean time, you can exclude pyproject.toml's from your sdists since black doesn't need it there

[16:05:40] <toad_polo> Or opt in to PEP 517 and make the necessary adjustments if possible.

[16:06:08] <toad_polo> Not always possible, the "exclude from sdist" is what we're doing in setuptools for the moment.

[16:07:10] <ngoldbaum> sure but then it's still a problem for editable installs but point taken

[16:07:23] <ngoldbaum> i just added "." to sys.path *shrug* no biggie

[16:07:47] <ngoldbaum> one of these days i should look at using pyproject.toml instead of setup.cfg and setup.py, this project could probably use flit

[16:07:49] <dstufft> oh if it's the sys.path thing that's breaking ypu, the enxt pip should fix that

[16:07:56] <ngoldbaum> oh ok

[16:07:58] <toad_polo> If you did that you may want to also fill out the `[build-system]` section.

[16:08:22] <toad_polo> It'll fix you for a while, but eventually you'll want to opt in.

[16:09:05] <dstufft> setuptools has two build backends now (it used t only have one), the first one has slightly different semantics (It might be just the sys.path thing? I'm not sure) but was intended to be opt-in but pip defaulted to it implicitly

[16:09:28] <dstufft> so setuptools added a second backend that more closely matches the older semantics, and a new pip will default to using that instead

[16:09:42] <toad_polo> Just the sys.path thing at the moment.

[16:10:15] <dstufft> AIUI setuptools recommendation is to explicitly opt-in to the first one, and if you need your thing on sys.path do that in setup.py

[16:10:16] <dstufft> the other one is really jsut for pip to use implicitly

[16:10:37] <dstufft> oh yea, there's an issue a bout that too

[16:10:39] <toad_polo> But all the backwards compat stuff will go in the "default" backend. The ideal situation is that people will eventually opt in to the official one.

[16:11:20] <toad_polo> And either modify sys.path or avoid local imports.

[16:17:19] <ngoldbaum> https://github.com/yt-project/unyt/pull/63

[16:34:46] <toad_polo> ngoldbaum: I'm curious but I don't know how to best test versioneer, if you're interested in being a guinea pig, I'm wondering.

[16:35:00] <toad_polo> One sec, let me make a gist.

[16:38:38] <toad_polo> If you undo the sys.path change and change your pyproject.toml to this: https://bpaste.net/show/ac3c3cfcb76b

[16:39:04] <toad_polo> Does versioneer still do the same thing if you do `pip wheel -w dist` and `python setup.py bdist_wheel`?

[16:40:33] <toad_polo> Er, `pip wheel -w dist . --no-deps`

[16:41:59] <ngoldbaum> that last command made my system hang?

[16:42:33] <ngoldbaum> "setup.py bdist_wheel" works fine before and after changing my pyproject.toml

[16:43:13] <ngoldbaum> and pip wheel -w dist . --no-deps just kinda sits there

[16:43:21] <toad_polo> Hm...

[16:43:34] <ngoldbaum> before and after making that change to pyproject.toml

[16:43:40] <ngoldbaum> oh no, it's finishing

[16:43:53] <ngoldbaum> just slow, i guess build isolation's fault :)

[16:44:32] <toad_polo> Hm, something is very weird, I'm seeing it fail to import versioneer, but when I pip install versioneer in a virtualenv I can import it.

[16:44:44] <toad_polo> Not quite sure what's going on there.

[16:44:44] <ngoldbaum> yeah, it broke without the change to pyproject.toml, now with the change

[16:44:49] <ngoldbaum> nope, still doesn't work with the change

[16:46:12] <toad_polo> Annoying.

[16:46:26] <toad_polo> Though the way it's failing seems very weird to me.

[16:46:34] <ngoldbaum> heh, and i get a *different* error with my setup.py sys.path change :)

[16:47:04] <ngoldbaum> https://bpaste.net/show/5f7d8e50c459

[16:54:36] <toad_polo> https://github.com/warner/python-versioneer/issues/193

[16:56:38] <ngoldbaum> toad_polo: sadly no commits since 2017

[16:56:54] <toad_polo> Ah. Why do people use this?

[16:57:12] <ngoldbaum> i think it got popular among a few scientific python packages

[16:57:42] <ngoldbaum> i like it because it more or less naturally solves the "get a version from git" problem and i don't really ever need to think about it

[16:57:45] <ngoldbaum> at least until now...

[16:57:57] <toad_polo> I guess time to get people to switch to `setuptools_scm`?

[16:58:57] <ngoldbaum> i thought that setup_requires was fundamentally broken because it uses easy_install?

[16:59:04] <toad_polo> It basically is yeah.

[16:59:26] <toad_polo> But if you use `pyprjoect.toml` that path never gets hit.

[16:59:26] <toad_polo> *`pyproject.toml`

[16:59:34] <toad_polo> And if you don't, the situation is even worse in some ways.

[17:00:51] <ngoldbaum> clearly a golden opportunity for someone to fork versioneer and make it work nicely with pep 517/518, get people to stop vendoring it too

[17:01:25] <toad_polo> Well `setuptools_scm` does basically the same thing.

[17:01:28] <toad_polo> Just without the vendoring.

[17:05:08] <ngoldbaum> then i guess a golden opportunity to add docs on how to do that with pyproject.toml to the readme

[20:31:53] <nicolasbock> Hi, I am finding that pip has issues with following links in a --constraint HTML when the host is a bracket protected IPv6 address (see https://github.com/pypa/pip/pull/6245). Is this a known issue with IPv6 addresses? Or am I just missing something?

[20:43:00] <ngoldbaum> nicolasbock: i'm not a pip developer, but maybe you want to add a test to your PR to make it clearer what the issue is? it's kinda hard to parse based on what you wrote in the PR description

[20:49:14] <nicolasbock> Thanks ngoldbaum

[20:49:55] <nicolasbock> I think you are right. That thought had occurred to me as well, and I am trying to figure out where best to put such a test. Thanks!