Log file Viewer

[06:57:32] <Guddddu> pip search django

[06:57:40] <Guddddu> Why does it not list the base django version available?

[07:03:03] <Guddddu> ls -ltr

[13:25:27] <graingert> Guddddu: base?

[13:26:10] <graingert> adiroiban: probably worth a ticket. Thoughts pradyunsg ?

[13:27:07] <pradyunsg> I'm not a 100% sure I understand what "base django version" means.

[13:56:19] <graingert> pradyunsg: oh sorry I was referring to the twisted pip error message

[13:56:33] <graingert> 17:25:03 <adiroiban> AttributeError: 'NoneType' object has no attribute 'excluded_of'

[16:27:15] <nanonyme> Hey, is it a bug that pip download doesn't follow setup_requires when --no-binary=:all is used?

[16:28:15] <nanonyme> It results in impossible-to-build things with build isolation

[16:28:42] <nanonyme> Assuming pip can't dynamically fetch things

[16:29:28] <graingert> nanonyme: hmm I think setup_requires is dead or dying

[16:29:40] <graingert> and it's supposed to be replaced with build-system.requries

[16:30:47] <nanonyme> Well, would pip download follow *that*?

[16:31:19] <nanonyme> We noticed pip download --no-binary=:all pyusb definitely does not download all relevant build dependencies

[16:33:42] <ngoldbaum> setup_requires is setuptools-specific and uses easy_install in the background, maybe it just never worked properly with build isolation?

[16:50:12] <dstufft> nanonyme: I think build isolation still requires using wheels for build dependencies FWIW

[16:50:21] <dstufft> because of bootstrapping concerns

[16:51:30] <nanonyme> dstufft, well, --no-binary=:all apparently allows source wheels

[16:51:52] <nanonyme> But the thing is, it doesn't follow setup_depends *at all* for download

[16:52:58] <nanonyme> dstufft, was there some standard way for a distro to provide system seed of wheels?

[16:54:01] <dstufft> nanonyme: I don't. remember TBH, I think --index-url is passed to that, so you can use that

[16:54:15] <dstufft> or you can disable build. isolation and just use distro build-eps

[16:54:18] <dstufft> deps*

[16:54:30] <nanonyme> dstufft, this build system has no network connectivity

[16:54:46] <nanonyme> We need to entirely depend on pre-downloaded/pre-seeded content

[16:54:57] <dstufft> nanonyme: --index-url can be a filesystem path

[16:54:58] <dstufft> or --no-index // --find-links

[16:55:07] <nanonyme> Right

[16:55:55] <nanonyme> Many distros seem to have a /usr/share/python-wheels but but

[16:56:59] <dstufft> I think those are for ensurepip

[16:57:16] <nanonyme> Ack

[16:57:32] <dstufft> nanonyme: I would expect a distro to just disable build isolation and use their normal build-deps mechanism TBH

[16:57:40] <dstufft> but maybe that's not workable for some reason

[16:58:41] <nanonyme> dstufft, we can. I heard rumours of it talks of it ending up removed, hence why this started in the first place

[16:59:23] <dstufft> nanonyme: I don't *Ithink* there is plans to remove --no-build-isolation, there are plans to eventually remove the legacy install paths

[17:00:03] <nanonyme> Though TBH it would be nicer if we could NO_BUILD_ISOLATION=1 as environment variable and we could just make the build system set that by default

[17:00:10] <toad_polo> This is part of the raison d'être for `build `

[17:00:28] <nanonyme> toad_polo, what do you mean?

[17:01:07] <toad_polo> `build` (the poorly named PyPA project) has first-class support for "bring your own build environment".

[17:02:11] <toad_polo> Distros can use it to build a wheel using PEP 517 without isolation, then they install the wheel in a separate step, either using `pip` or a to-be-completed minimal wheel installer.

[17:03:21] <dstufft> nanonyme: if you don't go down the pypa/build path, you can set any pip option as an environment variable fwiw

[17:04:02] <nanonyme> dstufft, that I didn't know of. What magic handles this? I didn't find it through Github searches

[17:04:16] <toad_polo> I think there's an open issue about `pip download` picking up build dependencies. Once that is fixed, it's a lot easier to build an offline build system.

[17:04:51] <nanonyme> Right. But the thing here is, disabling build isolation kinda works. We already do ship the missing things in the system

[17:04:56] <nanonyme> Build isolation just ignores them

[17:05:18] <toad_polo> Yeah, then pypa/build is probably what you want instead.

[17:05:38] <toad_polo> Once you have wheels pip won't need any build dependencies.

[17:07:08] <nanonyme> toad_polo, so is the correct thing for us to do really then to ship pypa/build in our sdk?

[17:16:58] <toad_polo> I don't know all the details of your system or your sdk. If you are actually shipping something to end users then I'd probably just build wheels or other binaries for the platform(s) you support. That will be the easiest thing by far. If you are acting as something like a distro, then having pypa/build available at the build stage is probably best.

[17:17:55] <toad_polo> None of this stuff is designed to be installed in one big global environment shared between build and run times, though it's possible that won't really cause you any problems.

[18:50:14] <nanonyme> toad_polo, it's actually a bit complex. We build a flatpak runtime. Other people (developers) build applications on top of it. Applications are isolated from each other, they share runtime. The problems come when developers want to semi-automatically generate source tree to be installed into the app (let's ignore the fact that they also package non-Python packages here). These packages occasionally

[18:50:16] <nanonyme> fail to build because build isolation prevents them from seeing packages in the runtime

[18:50:53] <nanonyme> toad_polo, the entire thing is based on assumption that builds are reproducible and actual builder has zero network access. Manifests tell where sources should be downloaded from and staged into source root for builder

[18:53:15] <nanonyme> We're currently using pip but build isolation is causing a lot of issues. The most obvious option is to just use pip with build isolation disabled. I'm not sure if this is the *right* approach though.

[19:10:06] <mcepl> jaraco: sorry for bothering you with non-pypa question here, but is there anywhere some comparison which version of https://github.com/python/importlib_resources/ corresponds to which version of importlib.resources in stdlib? E.g., which one is what's in 3.8.6?