Galaxykit has a fairly simple structure:
(galaxykit) henderson@mars => tree .
.
├── CHANGES.md
├── CONTRIBUTE.md
├── galaxykit
│ ├── client.py
│ ├── collections.py
│ ├── command.py
│ ├── container_images.py
│ ├── containers.py
│ ├── containerutils.py
│ ├── groups.py
│ ├── namespaces.py
│ ├── registries.py
│ └── users.py
├── LICENSE.md
├── README.md
├── setup.cfg
└── setup.py
Let's work through these files individually:
A changelog, tracking all the updates to the code.
This file, with advice on how to effectively contribute to galaxykit.
This is the GPLv2, which is the same licence galaxy_ng is distributed under.
Landing page.
Currently just contains a few linter settings.
All the metadata and things used when releasing this utility on PyPi.
The source directory, containing all the code that goes into galaxykit.
This file contains the GalaxyClient object, which is essentially a single authenticated context for making requests against an existing galaxy_ng instance. This file and command.py
contain the primary two interfaces to interacting with galaxykit.
Functions for managing collections.
The command-line interface logic - this is what gets run when you invoke galaxykit directly on the command-line. Currently in a bit of a hacky state, as it's grown faster than we can refactor it. An extensive refactor is in progress - check out this PR if you want to review the changes.
For interacting with individual container images (currently only contains 1 function for deleting a particular image (as opposed to deleting a container which includes all the associated images.))
Functions for dealing with containers as as discrete units (deleting, setting metadata.)
This code abstracts over common podman
or docker
commands for uploading or downloading container images from a galaxy_ng instance.
Adding/deleting/modifying the permissions of groups.
Creating and deleting namespaces.
Adding new remote container registries.
Adding/deleting users.
Please run the black
code formatter on your code before opening a PR. An easy way to ensure this is done is to install the pre-commit hooks bundled with this repository for any PRs. This is as simple as:
pip install pre_commit
pre-commit install
pre-commit install-hooks
If you don't, CI will make suggestions based on black, and we'll need to get those suggestions into your branch before we merge the PR.
So far we've been using twine
to upload releases to PyPi.
- Create a new branch and check it out, something like
release-v0.7.1
- Update the version number in
galaxykit/_version.py
. - Add the version that's going to be released the top of CHANGES.md, above all the changes that are going to be released.
- Push those changes, and make the PR in GitHub.
-
tag the release and push to git.
-
verify you are on the correct branch (you should be on main, just after having merged the new release PR and pushed the new tag.)
-
build the dist folder:
The below snippet builds both a binary wheel and a source distribution.
python setup.py sdist bdist_wheel
-
use twine to upload a release to test pypi:
twine upload --repository testpypi dist/*
Note that twine relies on a
~/.pypirc
file that defines the various servers, usernames, and other config it needs. -
install from testpypi to make sure things work as expected:
pip install -i https://test.pypi.org/pypi galaxykit
Once you have it installed, you can run tests with it, etc, to verify that it's working as expected.
-
release to real pypi
twine upload --repository pypi dist/*