-
Notifications
You must be signed in to change notification settings - Fork 78
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
Swap into using pyproject.toml and setup.cfg #135
Conversation
Also enables the use of automatic incrementation of the version number with the use of setuptools_scm and the creation of dev versions for local installs e.g. fprettify-0.3.8.dev10+g369708e.d20220831
run: | | ||
python -m pip install --upgrade pip | ||
pip install build | ||
python -m build |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the motivation to work outside a venv here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
pipx is strictly for console scripts with an entry point, pip is more permissive and allows for libraries and other packages. I would not impose pipx for the packaging step.
@awvwgk do we need both conda and pypi test workflows? Because the conda-forge feedstock draws from GitHub I think we should only unittest PyPi from 3.6-3.11-dev |
I don't see much difference between testing against the Ubuntu packaged Python and the conda-forge packaged Python. The Python version range is open to discuss, we have a pure Python package, so there shouldn't be much surprises, but of course we might have to support even Python versions which reached EOL like Python 3.5 and 3.6. Not sure about testing development Python version. |
There is no need to use a mix of Anaconda and pip when ti comes to setting up testing environments. We can solely rely on pip thus simplifying the CI workflows.
Remove use of conda from CI
@awvwgk same here, ready to merge |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot, I haven't reviewed this earlier because I'm not very confident with the tools employed here. Still, I suggest to merge this soon if there are no further comments from @awvwgk.
- name: Install project | ||
run: pip install . | ||
- name: Install project & dependencies | ||
run: pip install .[dev] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How does this work, how is .[dev]
resolved?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is part of setuptools
used to define optional requirements for the project. It reads this part from the setup.cfg
file.
[options.extras_require]
dev =
black
isort
pre-commit
coveralls
In this case we use it to store and install the development dependencies.
For more info have a look: https://setuptools.pypa.io/en/latest/userguide/dependency_management.html#optional-dependencies
If you want we can completely ditch the setup.cfg
file and move everything to pyproject.toml
@awvwgk are we happy with this or do you want me to make some changes? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks ready to go.
Fixes #132
Depends on #131 for README formatting