pyproject-hooks

[proper wolf]

Probably this channel needs to change to pyproject-hooks as well, right?

[junior urchin]

Indeed, and done!

[crude shard]

<---- and move it down a bit in the channel list to keep a-z order? 😉

[bronze holly]

That's been done!

[proper wolf]

I was wondering if there is any feedback from the maintainers about https://github.com/pypa/pyproject-hooks/pull/165

[junior urchin]

It's on my TODO list but, sadly, it's a long TODO list. 🙈

[proper wolf]

Thank you very much Pradyun

[noble grail]

anyone aware of efforts to provide distribution alike objects to build backend plugins that follow the same api everywhere, the differences are quite a pain sometimes

[silent zealot]

You mean some universal standard for build backend plugins?

[noble grail]

at least something partial - 'd like to be able to universally get stuff like distribution name, toplevel packages, related folders in vcs-versioning,

[junior urchin]

You'll have to ask the backend authors.

There's limited incentives for backend authors to do stuff like that though.

[silent zealot]

well, I have started prototyping hooks for poetry-core, which should allow you to get such info (or at least some of it)

but since there is no PEPified standard, you will have to look into each backend separately.

[rancid pollen]

Toplevel packages aren’t standardized. Depending on the build system, they’re determined in a different way, with a lot of configuration going on.

E.g. if hatchling’s behavior suits you, you can do

from hatchling.builders.wheel import WheelBuilder

root_path = Path()  # path with `pyproject.toml` in it
packages: list[str] = WheelBuilder(root_path).config.packages

That behavior is described here: https://hatch.pypa.io/latest/plugins/builder/wheel/#default-file-selection
Others behave differently, e.g. Flit only supports one package and used to not support src/<pkg>.

distribution name
That’s just the following, right? tomllib.loads(Path('pyproject.toml').read_text())['project']['name']

[noble grail]

as things look i'l focus on hatch and setuptools for now

[junior urchin]

I've set up trusted publishing configuration on PyPI.

[copper vigil]

I opened a PR that reduces execution time by about 10 ms but I'm not sure if we would want to do this https://github.com/pypa/pyproject-hooks/pull/202

[silent zealot]

private api and only 10ms gain? doesn't sound convincing to me

[copper vigil]

being private doesn't matter as that function will never go away but the issue is whether or not we think code might call stuff like atexit

[crude shard]

It is documented: https://docs.python.org/3/library/os.html#os._exit

[kindred temple]

I think it would be surprising if atexit handlers weren't called. atexit doesn't have a rich enough API to even query how many handlers there are. Where do you gain the 10ms?

[copper vigil]

workspaces, when there are a large number of members where you have to get the metadata for each one

it's just really slow so I thought that would be an easy win but it's not that big a difference compared to the hundreds of milliseconds that I don't have time to debug currently so yeah I'll just close the PR

[silent zealot]

if it never runs, then why is it significant?

[bronze holly]

I'm bumping pip's vendored copy of pyproject-hooks to v1.2.0. Is prepare_metadata_for_build_editable meant to have a return type of str | None? That seems inconsistent with prepare_metadata_for_build_wheel which only returns a string. I can't find anything in the specifications that would explain this difference. cc @junior urchin

[junior urchin]

I'm only seeing this now, and it's late where I am -- check PEP 660?

Oh, it might be the hack for how things work for PEP 660 implementation in pip?

[bronze holly]

Reading https://peps.python.org/pep-0660/#prepare-metadata-for-build-editable. I don't see anything allowing the hook to return None. prepare_metadata_for_build_wheel was initially typed to return str | None, but that got changed during review: https://github.com/pypa/pyproject-hooks/pull/167#discussion_r1160636565. https://github.com/pypa/pyproject-hooks/pull/167/commits/96a6691e8e19c5a6c24e4ac152e4839a0a9350aa

I don't know the specifics of PEP 517 or PEP 660 which is why I'm asking, but this does seem wrong in some way. It seems wrong that methods don't have the same return type .

[serene oasis]

Looks like an oversight to me. I'd do a PR to change it to str.

[bronze holly]

https://github.com/pypa/pyproject-hooks/pull/209

[hard inlet]

Awesome

[hard inlet]

https://github.com/graingert/read-toml

[noble grail]

how would one deal with in-tree backcends if package_name maps to a src folder directly ? the backend-path isnt exactly fitring

backend path of "." and a "evil" extra file to map it sems to be the way

[hard inlet]

for packages that just have pep621 metadata and no need for modules what's the minimal config for that?

https://github.com/celery/pytest-celery/blob/master/pyproject.toml#L15

it seems flit needs a module? is it possible to run with no build backend?

[charred patrol]

You always need a build backend because someone needs to understand different dist formats, at least you need to know how to zip things. But the backend can indeed be pretty minimal.

[noble grail]

@hard inlet in gumby elf, i have the src folder, that maps to the gumby_elf package, the build backend is in it i cant make it work easy

[hard inlet]

Ah you probably want a bootstrap build backend that does the path manipulation for you

[noble grail]

i made a single file that creates the module for the package and executes it