Log file Viewer

[14:06:12] <toad_polo> MrJones: Build isolation is PEP 518.

[14:06:43] <toad_polo> It may be that PEP 517 implies PEP 518 in the current implementation.

[14:07:01] <toad_polo> Why do you want to disable build isolation?

[14:08:08] <ngoldbaum> toad_polo: speaking of, there was a discussion on the numpy mailing list about this recently which you might not have seen and could probably weigh in on with more knowledge than other people in the thread

[14:08:24] <ngoldbaum> they were skittish about having a pyproject.toml because of pep 518

[14:08:29] <toad_polo> ngoldbaum: Link?

[14:08:54] <toad_polo> Yeah, there's a lot of FUD about PEP 517/518 and not a lot of people working with us to try and improve it :(

[14:09:12] <ngoldbaum> https://mail.python.org/pipermail/numpy-discussion/2019-July/079833.html

[14:09:20] <ngoldbaum> lol mailman doesn't handle html e-mail well

[14:09:24] <toad_polo> Half the purpose of PEP 517 is to make `pip install X` more likely to *just work* for stuff like numpy and scipy (though not those specifically)

[14:09:26] <ngoldbaum> they should move to mailman3...

[14:09:58] <ngoldbaum> toad_polo: numpy (justifiably) IMO has to be conservative and lots of people treat python packaging tooling as black magic

[14:10:03] <ngoldbaum> or a black box anyway

[14:10:27] <ngoldbaum> it's hard to fix :/

[14:11:09] <toad_polo> Yeah but even so a lot of the PyData stack has some of the most challenging builds out there.

[14:11:19] <toad_polo> Which is one reason conda is so popular in that sub-ecosystem.

[14:12:08] <toad_polo> It would be nice to see either early adoption or some "allowed failures" CI jobs or something.

[14:14:02] <toad_polo> Most of that PEP 517/518 stuff only affects people not building wheels, so it depends on how much of the platform x version matrix you have populated with wheels, but I understand the reluctance to do stuff that *requires* a recent version of `pip`.

[22:18:43] <MrJones> toad_polo: because of https://github.com/pypa/pip/issues/6718

[22:19:27] <MrJones> I know breaks build-system.requires I can handle that, but I can't make build isolation work in this environment so I really need it to be off

[22:20:09] <MrJones> so how can I really turn it off? --no-build-isolation sadly doesn't seem to disable it for the deps, I need it to remain off for the entire call for all packages it may try to install

[22:21:38] <MrJones> if there is no way to turn it off permanently during an entire pip run then I may need to file a ticket. I just assumed surely there would be, naively I thought --no-build-isolation actually would but looks like it doesn't (or if it's supposed to then it doesn't seem to be working right)

[22:22:04] <MrJones> just didn't make a ticket yet because I assumed I missed something, like a way to actually turn it off

[22:35:59] <MrJones> ok I'm not fully sure.... is there a tell-tale sign that build isolation is used? given all I'm seeing it would make the most sense if it is but I'm actually not sure from the output

[22:37:35] <MrJones> bbl will check later for messages. any hints on how to see from the output when build isolation is employed would greatly help me in making sure I don't file a useless ticket here (which I'd rather avoid)