pystac upstream split

[Sebastiaan Couwenberg]

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.
  
> 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?

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.

Updating the extensions with cherry-picked patches is also an option, but uscan won't inform you about available updates.

Is the pystac repo now some kind of monorepo in which all the related projects live?

> 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.

> 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.

Kind Regards,

Bas

-- 
  PGP Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1