[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How does one package a multirepo project?



Hi Julien, and others,

Quoting Julien Puydt (2020-10-19 09:15:28)
> I was trying to update the ipywidgets package. It once had a quite 
> normal upstream, but then things went wild, if not stellar : they went 
> monorepo.
> 
> For those lucky ones who never crossed the principle, the idea is to 
> have a single repository, and make dozens of different packages live 
> within. Basically, different directories now are different packages, 
> with different release schedules. At the moment, 
> https://github.com/jupyter-widgets/ipywidgets has 936 tags.
> 
> There are several issues at hand :
> 
> - uscan doesn't work correctly anymore, as the multiplication of tags 
> makes them disappear in the list quite fast ;

Please see uscan v4 and its version types "group" and "checksum".

If you are already aware of that, then perhaps by "doesn't work 
correctly" you really mean "doesn't work same way as I am used to"?


> - and what does one want to watch exactly anyway?

Ideally we want to watch upstream releases of all upstream parts.

If "upstream releases" are git commits, then watch that.

If "upstream releases" are something more obscure like timestamps of 
files (yes, some do that!) then somehow watch that - or try convince 
upstream to also/instead use an easier watchable mechanism.


> - even if uscan could keep up, how does one get the source? It should 
> basically be a checkout of a different commit for each different 
> directory!

Please see uscan v4 and its mode=git.


> - how does one even put a version number of this for a Debian package? 
> (I guess something like "Provides: foo (= 3.14), bar (= 2.72)" can 
> help a little, but what about the main package?)

If main package is not versioned upstream, then I would say that's a 
strong indication that you really want to track each underlying part as 
a separate Debian package instead - i.e. that upstream "main package" 
translates to a Debian metapackage.


> PS: and to package the next ipywidgets, I started to work on lumino ( 
> https://github.com/jupyterlab/lumino) with the same problem. In my 
> experiments I numbered the main package 0~20200824+git93880412-1... 
> which is not ideal.

Why is that not ideal?

I would drop the git part as it cannot be sorted (there is no guarantee 
that next git commit on same day leads to a higher version number).  
I.e. use 0~20200824-1 and if you come across needing to issue a second 
release on same day then use 0~20200824.1-1 for that.


You might find some inspiration in the source package 
jsbundle-web-interfaces which uses version type "group" and mode=git, 
and sets individual version numbers for each binary package.

Another example is matrix-mirage where one component is fixed at a 
specific release.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Attachment: signature.asc
Description: signature


Reply to: