pystac upstream split

[Antonio Valentino]

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