Log file Viewer
#pypa-dev logs for Tuesday the 18th of February, 2020
[02:33:44] <toad_polo> In this case I have a little wrapper script that does some other stuff as part of the build: https://github.com/dateutil/dateutil/blob/110a09b4ad46fb87ae858a14bfb5a6b92557b01d/tox.ini#L90
[02:36:20] <toad_polo> But you can replace the `python release.py build` with `python -m pep517.build ...` and then `tox -e build` will work. If you want to generate the stuff in `dist/` you do `python -m pep517.build -b -s -o {toxinidir}/dist`
[02:37:10] <toad_polo> Though if you aren't already using `tox` then I dunno if that saves you anything, because you have to have `tox` installed.
[02:37:42] <toad_polo> And the only dependency installed in the venv would be `pep517`, since the other build dependencies would presumably be declared in `pyproject.toml`.
[02:38:16] <toad_polo> Also, I strongly recommend getting rid of this: https://github.com/BloggerBust/test_pep_420/blob/90d15b394328bfe36955be1f2dd0822431215ba9/setup.cfg#L28
[02:40:30] <toad_polo> When you create your wheel, I'm pretty sure it's including two packages, one called `implicit_namespace` and one called `test`.
[02:40:50] <toad_polo> This is why I said that if you are going to use `find_namespace` you pretty much *must* use the src/ layout.
[02:41:36] <toad_polo> The alternative is to do something with whitelists or whatever, but that's annoying and I can never remember if I'm doing it right. https://hynek.me/articles/testing-packaging/
[10:31:02] <dustfinger> Yes, it is adding test package to the wheel. I noticed that last night and I thought I could get rid of it using [options.packages.find] section with an exclude = test.*, but that does not seem to work. I tried also adding an include = implicit_namespace_foo.*. Not sure why it isn't working.
[10:33:10] <dustfinger> I think I will just add a configure.py script with commands to install build dependencies, package, clean etc. Installing tox would add a lot of other dependencies and I wanted to make my venv as lean as possible
[14:13:33] <dustfinger> Okay, maybe the documentation is just out of date, but the note section from https://setuptools.readthedocs.io/en/latest/setuptools.html#configuring-setup-using-setup-cfg-files says that keys from files, entry_points and backwards_compat are not supported.
[14:15:03] <toad_polo> Entry points is documented under "options": https://setuptools.readthedocs.io/en/latest/setuptools.html#options
[14:15:15] <dustfinger> pradyunsg: that is, to implement editable support for fully declarative setup is in the backlog?
[14:16:17] <toad_polo> Because the way distutils does its marshalling of resources is to incrementally build the package rather than getting a list of everything that needs to be done and then doing it.
[14:34:08] <dustfinger> According to PEP-420 implicit namespace packages are not supposed to have a __file__ attribute (https://www.python.org/dev/peps/pep-0420/#differences-between-namespace-packages-and-regular-packages). What is the significance of namespace packages not having a __file__ attribute?
[14:46:06] <dustfinger> Ahh, I think it is just because a namespace package is a package that is not a module, but apparently __file__ has no semantic meaning and is optional (https://docs.python.org/3/reference/import.html#__file__) so I don't know what to think.
[14:48:02] <dustfinger> I found that PEP-420 implicit namespace package does have a __file__ attribute (https://github.com/BloggerBust/test_pep_420#org84bfc72). Technically that is a bug, but I am not sure if anyone really cares if the specification of the __file__ attribute is so unclear in the first place.
[18:55:56] <sumanah> PyCon Packaging Summit organizers such as pradyunsg: and toad_polo: hey is https://us.pycon.org/2020/hatchery/packaging/ ready for me to link to in other places?
[18:56:18] <sumanah> like in https://discuss.python.org/t/pycon-us-2020-do-we-want-conduct-a-hatchery-event-for-python-packaging/2603/19 ?
[18:56:28] <sumanah> not just for me to link to, but, people have asked me about it, because of the pip work
[18:57:37] <toad_polo> sumanah: Yes and no. Yes in the sense that everything on the page ia accurate and the forms all work, but no in the sense that I was planning to draft an announcement today to go with it that will have some more context.
[18:57:55] <toad_polo> So if someone personally asks you for more information you can send them there, but I wouldn't tweet about it or whatever.
[18:58:15] <toad_polo> I was actually going to ping you soon-ish (hopefully tonight) about getting it announced on the PyPA twitter.
[18:58:45] <sumanah> Per [the Packaging Summit page on the PyCon website](https://us.pycon.org/2020/hatchery/packaging/) the topic proposal process is via Google Form:
[18:58:45] <sumanah> > Propose a topic: http://bit.ly/python-packaging-summit-2020-topics (closes 7th March 2020 AoE)
[18:59:00] <sumanah> this is in https://discuss.python.org/t/packaging-summit-2020-potential-topics-for-discussion/3040/10
[18:59:26] <sumanah> if you want to tweet something and then nudge me via email or something, I will RT it
[19:00:55] <sumanah> toad_polo: also, were you (like me) under the impression that pycon.blogspot.com would (today) have a new blog post about all the Hatchery events? because I would have to look through my email to check why I thought that, but I thought that
[19:02:23] <toad_polo> sumanah: We can do it either way, but it might be nice to have the annoucement originate on the ThePyPA feed so people know about that account.
[19:03:31] <toad_polo> Regarding the other thing, I only remember that there was recently a deadline to have the website ready, I don't think I read carefully enough to see if there was any sort of blogging thing going on.