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

Replacing flit #1655

Merged
merged 4 commits into from
Feb 27, 2023
Merged

Replacing flit #1655

merged 4 commits into from
Feb 27, 2023

Conversation

Torxed
Copy link
Member

@Torxed Torxed commented Feb 27, 2023

PR Description:

As discussed in pypa/flit#522 and #832 the future of flit doesn't appear appealing to me and others.

So while we're ahead, I'm replacing flit with just setuptools and relying on it to build for us.
This allows for external dependencies as well via:

[project]
dependencies = [
    "pyparted",
]

or setup.cfg

[options]
install_requires =
    pyparted

And if it's a build-only specific dependency put it in:

[build-system]
requires = ["pyparted"]

A good reference on how to include the profiles and stuff was from here: https://godatadriven.com/blog/a-practical-guide-to-setuptools-and-pyproject-toml/

Tests and Checks

  • I have tested the code!

@Torxed Torxed merged commit 2a17ba9 into master Feb 27, 2023
@Torxed Torxed deleted the change-build-system branch February 27, 2023 22:51
@Torxed
Copy link
Member Author

Torxed commented Feb 27, 2023

I've verified that both /examples/ and /profiles/ contain all the profiles.

@svartkanin
Copy link
Collaborator

@Torxed I didn't realize this happened until now that I was trying to merge in master into the pyparted branch. Isn't this sort of a move backwards? Wouldn't it rather make sense to use poetry instead as it has full support for pyproject.toml and comes with a lot of other neat futures as well we could utilize?

@Torxed
Copy link
Member Author

Torxed commented Mar 17, 2023

with a lot of other neat futures as well we could utilize?

Until we do, the move backwards is just a simplification which would hopefully be less prone to regressions and issues as it's pypa's reference implementations (knock on wood). I simply chose python-setuptools as the PEP517 backend because it's the simplest one and also to keep it in the pypa family:

Anything specific we'd like from poetry? I think we evaluated poetry in the very beginning :)

@svartkanin
Copy link
Collaborator

It makes sense to have them all operating from the same set of tools. Some issues I have experienced with setuptools were primarily related to dependency management. It run into conflicts and wasn't really able to handle different versions of the same packages properly. Setuptools is a more complex tool to handle things which needs some familiarity as well probably.

@svartkanin
Copy link
Collaborator

Maybe I'm missing something but do we actually need a setup.cfg file? setuptools seems to be able to handle pyproject.toml just fine, so why use them both https://setuptools.pypa.io/en/latest/userguide/pyproject_config.html ?

AFAIK setuptools is not able to install dependencies only, so it will be (a bit) more cumbersome for devs to get started as they have to dig out the required packages from the toml and then install them.

Setup with Poetry

git clone...
poetry env use python3.10  # use or create new virt env
poetry install   # install all dependencies in current virt env

Build project

poetry build # builds wheel

Install project

poetry install

:)

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

Successfully merging this pull request may close these issues.

None yet

2 participants