On 8/11/26 10:48 PM, Antonio Valentino wrote:
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?
Using substvars in d/control, e.g:
Package: pystac-ext-eo
Version: ${pystac-ext-eo:Version}
and generating the pystac-ext-eo.substvars file in d/rules using the .toml
files.
https://www.debian.org/doc/debian-policy/ch-source.html#variable-substitutions-debian-substvars
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)
May rename it to python3-pystac-extensions if it only contains those.
That could also be split into its own source package which bundles all the
extension like nodejs packages do (using the checksum version and multiple
upstream tarballs).
https://wiki.debian.org/Javascript/GroupSourcesTutorial
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.
pytest-pystac also doesn't have tags in the upstream repo, unlike core and the
extensions. Possibly because it hasn't been blessed as stable yet.
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
Kind Regards,
Bas
--
PGP Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
_______________________________________________
Pkg-grass-devel mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-grass-devel
