pystac upstream split

[Sebastiaan Couwenberg]

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