Log file Viewer

[09:44:14] <snktdg> pradyunsg: ping

[09:57:47] <pradyunsg> snktdg: pong

[10:13:16] <snktdg> pradyunsg: Do you mind if I PM?

[10:15:45] <pradyunsg> snktdg: what's this about?

[10:19:52] <snktdg> pradyunsg: Apologies, I had PM'd you on twitter (sanketdg) regarding pypa.

[10:55:16] <pradyunsg> Well, they quit. 🤷🏻‍♂️

[10:56:30] <pradyunsg> Fun.

[10:56:55] <pradyunsg> Does anyone know how to set up a message to be sent by chanserv when folks join a channel?

[10:57:25] <pradyunsg> I think we should have one saying "wait for around 2 hours if you don't get an immediate response". 🤷🏻‍♂️

[11:50:05] <dustfinger> Why use pep517.build . over pip wheel --no-deps --use-pep517 --wheel-dir dist .?

[11:52:06] <dustfinger> okay, I see one reason. pep517.build uses pyproject.toml allowing you to configure the build system, whereas pip wheel --use-pep517 does not recognize pyporject.toml

[11:53:46] <dustfinger> So here is another question. If I am going to use the build-backend setuptools.build_meta anyway, is there any reason why I should use pep517.build over pip wheel --use-pep517?

[12:55:07] <toad_polo> dustfinger: pip wheel is not for building wheels.

[12:55:57] <toad_polo> It's for building "wheelhouses", like it's for getting everything you need in wheel form in a directory.

[12:56:32] <toad_polo> It does use pyproject.toml, no idea what gave you the impression it didn't.

[12:57:55] <toad_polo> Anyway there is no canonical recommendation for what you should use to build wheels or sdists, all the documentation says setup.py invocations, but that's because we haven't agreed on a replacement yet.

[12:58:50] <toad_polo> I prefer pep517.build for now, and eventually a tool similar to that.

[12:59:07] <toad_polo> Note that pip cannot build an sdist for you.

[13:06:24] <dustfinger> toad_polo: I renamed my pyproject.toml and was still able to build a wheel without it using the command - pip wheel --use-pep517 --no-deps --wheel-dir wheel_dir .

[13:06:53] <dustfinger> That is why I thought it doesn't use pyproject.toml, but I guess it probably just uses defaults if the toml doesn't exist, so it was a false assumption on my part.

[13:07:05] <toad_polo> dustfinger: Yes, it doesn't rewrite a pyproject.toml.

[13:07:31] <dustfinger> That is a good point about sdist. I didn't consider that.

[13:07:47] <toad_polo> Ideally the replacement for pep517.build wouldn't either.

[13:10:35] <dustfinger> Why do you prefer pep517.build over telling pip wheel to create a wheel for your package, but not its dependencies, thus not creating a wheel house? The end result appears to be the same.

[13:24:21] <dustfinger> why would you say that it would be ideal if a replacement fpr pep517.build did not have an option for building an sdist? I ask because build_sdist is a mdandatory hook in pep517.

[14:03:52] <dustfinger> np. I see the point. It is about separation of concerns. The build module is about building packages. sdist are snapshots of the source tree so very different concepts.

[14:46:34] <toad_polo> dustfinger: No.

[14:47:01] <toad_polo> What I meant was that the replacement for pep517.build would not require `pyproject.toml`.

[14:48:25] <toad_polo> Just fall back to a default that is roughly equivalent to what you get now.

[14:48:46] <toad_polo> You can do whatever you want, `pip wheel` will work to build a wheel.

[14:50:03] <toad_polo> I think the fact that you need to add a bunch of flags to the default behavior to get it to avoid doing something very unlike what you'd want it for if you just want to build your project for distribution is one reason why you'd want to avoid it.

[14:50:23] <toad_polo> And the fact that there's no equivalent for building sdists is a problem.

[14:50:57] <toad_polo> I also think there's no reason for `pip` to further expand its scope.

[15:22:26] <dustfinger> I don't want to avoid it. I was just interested in your thoughts.

[15:22:42] <dustfinger> How do you install packages without pip?

[15:26:19] <dustfinger> What is the correct way to stor a version number in package_name/_version.py? I am currently putting the version directly in the file like this: 0.0.3

[15:26:43] <dustfinger> Then I am setting the version in setup.cfg using the file: directive

[15:27:50] <dustfinger> err. nm about my question regarding installation without pip. I misread one of your comments.

[15:32:24] <ngoldbaum> pradyunsg: you can change the topic for the channel,

[15:32:33] <ngoldbaum> although people don’t read so...

[15:35:47] <dustfinger> nottrobin: was I off topic?

[16:02:59] <pradyunsg> dustfinger: nope.

[16:03:32] <pradyunsg> ngoldbaum: there's only choices between bad and not good. 🙃

[16:05:25] <pradyunsg> dustfinger: if all you want is a wheel, pip wheel . --no-deps and pep517.build are nearly equivalent for nearly all use cases.

[16:06:06] <pradyunsg> pip wheel can't build an sdist and pep517.build uses different build isolation compared to pip.

[16:07:39] <pradyunsg> Neither is a good "just use X" answer for all use cases, which is something we'd want to fix in the short term. Which would be when someone finds motivation + time to do that.

[16:53:22] <dustfinger> Okay, I am going to be using pep517.build.

[16:55:00] <dustfinger> It seems to be somehwat common to define a __version__ attribute in a packages __init__.py. How would this be done for a PEP-420 implicity namespace package?

[17:14:10] <ngoldbaum> take a look at setuptools_scm

[17:14:29] <ngoldbaum> i don’t know offhand if it supports that use case though

[18:08:07] <dustfinger> Thanks, I will look into that.

[18:52:08] <toad_polo> Why would you need a version on an implicit namespace package?

[18:52:19] <toad_polo> Where would that even go?

[18:52:25] <toad_polo> You mean like `mynamespace.__version__`?

[18:53:27] <toad_polo> It doesn't make a lot of sense to do something like that IMO, since each of the packages in the namespace has their own version, and the "namespace package" is not a package at all, it contains no code and can't be installed by itself.

[19:44:01] <tos9> ^

[19:44:06] <tos9> that