search

MrMino / wheelfile

🔪🧀 API for creating and inspecting Python .whl files (wheels)
MIT License
29 stars 5 forks source link

build: implement pep621 with example build file #24

Closed kuwv closed 2 years ago

kuwv commented 2 years ago

@MrMino I updated the build to use your example with a pyproject.toml. The requirements files are really intended for deployments anyway.

Also, is this project just for learning or you going to maintain it?

MrMino commented 2 years ago

The build file is meant to be an exercise in dogfooding the library, and it serves as a sanity check. Whenever I'd build the release I first try to use a new version to build an older one, then compare the resulting wheel with what's released on PyPI to see what is missing.

To that end, the library assumes no reliance on any packaging specification format, and this is a conscious decision which I would like to keep.

The library was built for use within some of the systems we have at Nokia, which I'm not developing right now, hence the large gap in development.

I'll be coming back to this but right now it's hard for me to say when.

kuwv commented 2 years ago

@MrMino I'm not sure I understand what you mean. The changes I have proposed are dogfooding the local API. And the previous approach you were attempting could just be supported with a typical if __name__ == "__main__". Doing it through pip also allows the custom configuration arguments to dynamically reconfigure these builds.

The current process is masking the integration issues between this library and pip.

MrMino commented 2 years ago

integration issues between this library and pip.

Can you give an example? I'm not aware of any, and, to be honest, I don't see a connection between the build script and Pip.

kuwv commented 2 years ago

Yeah, installing extras doesn't work correctly with this current flow: pip install '.[test]' for example.

And, pip install -e . with pep660

MrMino commented 2 years ago

I don't think there's an inherent necessity to have those defined, but if it helps - you can add a pyproject.toml for it.

Not sure how would it mesh with the fact that it wouldn't be used for package metadata though.

The build script is used as a documentation example, and as such it is kept as simple and minimal as possible. __name__ == "__main__" isn't strictly necessary there (similarly, you wouldn't import setup.py), and adding parsing of pyproject.toml there is not something I see any value in, sorry.