consider using git+https together with a branch name or kuibit install
Each ET release is tied to a specific kuibit version and @Gabriele Bozzola allows the ET to create branches and tags in kuibit. Yet to then install kuibit the instruction in the ET use numeric version numbers 1.4.0
or so and thus a code which may not actually match up with the ET branch ET_YYYY_MM
of any release (unless special care is taken by the release coordinator to create a release branch of the version (tag) that will be used for the release).
It may be interesting to consider instead to use:
pip install git+https://github.com/Sbozzolo/kuibit@ET_2023_05
instead. At least from the point of view of consistent ET versions. The downside of course being that this probably breaks pip’s logic to compare newer versions and may inundate kuibit’s bug tracker with version numbers that are really ET versions and not kuibit version.s
Comments (2)
-
-
In addition, kuibit comes with an internal notion of version (`kuibit.__version__`), which is used for deprecated features or to check if some features are available. If I don’t change this,
kuibit@ET_2023_05
would still advertise itself as version 1.4.0, which might introduce some confusion. - Log in to comment
I can see another drawback to this. When you install kuibit with
pip install kuibit
, you are served the wheels from PyPI. These are very small files (460 kB) and are supposed to work immediately on all the supported architectures/versions.When you install kuibit from git, you have to download the entire repo (along with the tests, some data files, and so on, and the entire git history), which can be 100s of MBs - 1 GB. Moreover, you have to recompile the package locally. This should not be a problem for 99 % of the cases, but I would not be surprised if there were incompatibilities in some cases.
So, as developer, I would prefer sticking with PyPI for the slightly better user experience, but I do not feel strongly about this.