Dear Bas,
Il 11/08/26 20:35, Sebastiaan Couwenberg ha scritto:
On 8/11/26 7:41 AM, Antonio Valentino wrote:
* 22 extensions (each with a single python module)
If these are very small, that would be an argument to keep building
those from the same source as the Archive Team has complained about lots
of small packages (in the Node.js ecosystem) in the past.
Everything is in a single repository and we currently get the the
source tarball directly from github.
The original idea was (the one currently implemented in salsa and
still not fully working) was to generate multiple python packages from
a single source but I realized that pystac(-core) and the extensions
are versioned (and also released) independently.
This is an issue for the current implementation because all the debian
packages now have the same version.
Do you know if it is possible to control the version of the individual
packages generated form the same source tarball?
Binary packages don't have to use the same version of the source
package, this can sometimes be used instead of an epoch.
How can I do it?
Right now I have 26 packages with version 1.15.2-1.
I guess that I could make the debian version independent from the
upstream version but I don't know how to control the version of the
different generated packages
E.g the pystac version is 1.15.2 but the version of
pystac-ext-xarray-assets in the source archive is 1.0.0, and today it
has been bumped to 1.0.1.
Please note that the version of the installed package (and the dist-info
directory) is correct, just it does not matches the one of the debian
binary package for the various extensions.
In any case the single source approach would have limitations because
I would not be able to update the extensions independently.
What criteria does pystac upstream use to tag a new release?
In y understanding they have multiple project in a monorepo and they
plan to have version the various components independently:
$ grep version $(find . -name pyproject.toml)
./pyproject.toml:version = "1.15.2"
./core/pyproject.toml:dynamic = ["version"] # __version__ = "1.15.2"
./extensions/datacube/pyproject.toml:version = "2.2.0"
./extensions/sat/pyproject.toml:version = "1.0.0"
./extensions/xarray_assets/pyproject.toml:version = "1.0.0"
./extensions/item_assets/pyproject.toml:version = "1.0.0"
./extensions/raster/pyproject.toml:version = "1.1.0"
./extensions/pointcloud/pyproject.toml:version = "1.0.0"
./extensions/eo/pyproject.toml:version = "1.1.0"
./extensions/classification/pyproject.toml:version = "2.0.0"
./extensions/render/pyproject.toml:version = "2.0.0"
./extensions/version/pyproject.toml:version = "1.2.0"
./extensions/mlm/pyproject.toml:version = "1.4.0"
./extensions/scientific/pyproject.toml:version = "1.0.0"
./extensions/file/pyproject.toml:version = "2.1.0"
./extensions/mgrs/pyproject.toml:version = "1.0.0"
./extensions/timestamps/pyproject.toml:version = "1.1.0"
./extensions/sar/pyproject.toml:version = "1.0.0"
./extensions/view/pyproject.toml:version = "1.0.0"
./extensions/projection/pyproject.toml:version = "2.0.0"
./extensions/table/pyproject.toml:version = "1.2.0"
./extensions/label/pyproject.toml:version = "1.0.1"
./extensions/grid/pyproject.toml:version = "1.1.0"
./extensions/storage/pyproject.toml:version = "2.0.0"
./pytest-pystac/pyproject.toml:version = "0.1.0"
If only changes to core result in a new release which then also includes
accumulated updates to the extensions, there is an argument for
splittings the extensions off.
Apparently no, they tag and release extensions independently on
pystac-core, etc.
Updating the extensions with cherry-picked patches is also an option,
but uscan won't inform you about available updates.
I didn't consider this. Indeed it is an option.
The fact that uscan would not help in this case is not a big issue for
me, I'm registered to github release notifications in any case.
Is the pystac repo now some kind of monorepo in which all the related
projects live?
yes
Unless you have a different advice, I think that the cleanest solution
would be to have 25 independent packages and to get the source
tarballs from PyPI.
My gut feeling right now is that we don't want all of these separate
extension packages, but I don't have enough information to formulate
what I think would be the best solution.
For the time being I would like to keep the single source package.
Probably it is also a good idea to have only
python3-pystac-core
python3-pystac (which includes all the extensions and depends on
pystac-core)
python3-pystac-doc
python3-pytest-pystac would also be needed for autopkgtests
This one would be the only one with a mismatch between the debian
package version and the python package version.
For the mime being non of the packages in debian has a direct dependency
on the pystac extensions so they would not be impacted.
Switching to a with multiple extension packages or even multiple source
packages would be always possible int the future if needed.
Of course I will need again your help for the review of the new
packages and the first upload.
That's of course no problem if it comes to that.
If the above plan sounds good for you then no new repository is needed.
I will still need you to sponsor the first upload.
I will first re-organize the package to include all the extensions in
python-pystac, and then I will introduce patches to the new versions of
the extensions released in the meanwhile,
kind regards
--
Antonio Valentino
_______________________________________________
Pkg-grass-devel mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-grass-devel
