Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace setup.py workflow #1724

Closed
merelcht opened this issue Jul 25, 2022 · 4 comments
Closed

Replace setup.py workflow #1724

merelcht opened this issue Jul 25, 2022 · 4 comments

Comments

@merelcht
Copy link
Member

Also note that setup.py is deprecated and we will have to move away from it in general

Originally posted by @datajoely in #1607 (comment)

The setup.py workflow is deprecated and we should move towards another way of packaging in Kedro. Ideally we would move to a pyproject.toml driven workflow as described here: https://packaging.python.org/en/latest/tutorials/packaging-projects/, but until that's the official way of doing things we should probably use setup.cfg file: https://setuptools.pypa.io/en/latest/userguide/declarative_config.html

@merelcht
Copy link
Member Author

merelcht commented Aug 22, 2022

Check what Alloy team is doing for packaging, would be good to understand what approach they are taking and why.

@deepyaman
Copy link
Member

Also note that setup.py is deprecated and we will have to move away from it in general

As mentioned in the second paragraph of the TL;DR, direct invocation of setup.py is deprecated, not the use of setup.py itself. It should be a relatively small change to properly specify the build system. Moving to setup.cfg-/pyproject.toml-based workflows do have their own advantages, but we can separate this until the pyproject.toml approach is out of beta and/or we know whether to move down the setup.cfg or pyproject.toml route, in order to minimize documentation (and other user-facing) changes.

@datajoely
Copy link
Contributor

The argument for adopting setup.cfg is that it makes the eventual migration much simpler. So it's just a question of when you front load your development effort - One huge ticket or two smaller ones.

@merelcht
Copy link
Member Author

merelcht commented Jan 3, 2023

Closing in favour of #2152

@merelcht merelcht closed this as completed Jan 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants