-
Notifications
You must be signed in to change notification settings - Fork 75
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
Publish all releases on PyPI #1579
Comments
Thank you for reporting us your feedback! The internal ticket has been created: https://warthogs.atlassian.net/browse/CRAFT-2572.
|
Hi @bittner. Out of curiosity, what is your use-case for consuming Charmcraft as a Python package (instead of the snap)? |
Most importantly, installing a snap in a Apart from that, I want to work on Juju Charms preferably with a pure Python tool chain. Also, I think it's fair to assume that developers using a popular (Open Source) Python package expect that it can, primarily, be installed from PyPI. As for another argument, I use Ubuntu, and of course, I can install a snap - at least on my development machine -, but I have other people in the teams that I work with that prefer to use macOS or Windows. How can I convince them that it's great to work with Juju Charms when it requires them to abandon their preferred environment? |
Thank you for the reply, this is very interesting. I definitely hear you on the Docker restriction on snaps, and I didn't know people were able to effectively use Charmcraft as a Python package in non-Linux environments. |
TBH, I've not tried charmcraft on anything but Ubuntu, but I assumed that the OS-independent nature of Python is why charmcraft was implemented with it. Not sure what charmcraft features would require to be limited to Linux, or even Ubuntu. The snap packaging, OTOH, certainly is a limiting factor. A friend of mine who uses Arch Linux preferred to come up with a Vagrant setup (with Ubuntu) for charm development. As by the example in #1580 (comment), the recent improvements on charmcraft were good to have released on PyPI, so that a few more CI use cases could be made possible. 💯 |
I was thinking of building using managed lxd instances, but if you're using this in a Docker container that wasn't your use case. |
homebrew does prefer pure pypi toolchain as well, I think it is good to publish sdist to pypi for downstream packaging manager use in general |
Adds two Tox environments that help with publishing the Python package on PyPI. - `tox -e package` can be used for linting to help detect packaging issues. - `tox -e package -- upload` allows to publish the package on PyPI. - `tox -e ensure_version_matches $GIT_TAG` verifies that the package version matches the semantic Git tag on the current commit. This is used by the GHA configuration to prevent a mismatch of tags and the version of the published package. To make publishing work, you need to add the 2 secrets `PYPI_USERNAME` and `PYPI_PASSWORD` to [Settings ➜ Secrets ➜ Actions](https://github.com/canonical/charmcraft/settings/secrets/actions) with the PyPI access token for the project, as described in the [Python packaging user guide](https://packaging.python.org/en/latest/tutorials/packaging-projects/#uploading-the-distribution-archives). ## Related - #1579 - [Is `setup.py` deprecated?](https://packaging.python.org/en/latest/discussions/setup-py-deprecated/) – _The use as a command line tool is deprecated_ Co-authored-by: Alex Lowe <[email protected]>
any luck on this thread? |
@tmihoc Any chance we can get the (latest) versions missing on PyPI uploaded? The automation is now in place. The publishing command ( |
@bittner I'll be releasing 2.7.1 and 3.1.0 to PyPI with this shortly. |
All releases up to 2.7.0 and 3.0.0 have been backfilled on pypi. Marking as resolved. |
Great, thanks for filling the gaps! 💯 Looking forward to seeing the publish workflow run for the first time in this repo. 🤖 |
What needs to get done
There are releases of the charmcraft Python package on GitHub, which are not on PyPI.
Why it needs to get done
It's more obvious, more natural to install the Python package from PyPI.
A release on GitHub suggests that there is also a release on the canonical Python package platform. Not keeping the releases in sync creates additional confusion.
The text was updated successfully, but these errors were encountered: