[RFC] Rolling release on pypi

[legalsylvain]

Hi all,

• The current release process of this library requires to make new release on github, which is not done very often, and which requires additional actions from the project administrators.
• In the meantime, openupgrade project requires the "allways up to date" library, so in all the openupgrade and openupgradelib documentation, it is written to NOT install via pypi, but directly the matest revision on github. (pip install git+https://github.com/OCA/openupgradelib.git@master#egg=openupgradelib)

What about to push on pypi on each new commit ? AFAIK, it requires to change this github workflow : https://github.com/OCA/openupgradelib/blob/master/.github/workflows/publish.yml

[pedrobaeza]

Not sure such hammering is the best. First problem I see is that we have to lose a consecutive numbering, or we have to put an auto-incremental one. But let's see other more experienced with pypi what thinks.

[legalsylvain]

Thanks Pedro, for your answer.

In fact, not sure it's good to make rolling release, and indeed, perhaps that generates problems... But in that case, I don't see the point of deploying the library on pypi, if we know that it is obsolete, and we recommend not to install it via pypi. but maybe I didn't understand.

But let's see other more experienced with pypi what thinks.

@sbidoul ? ;-)

[sbidoul]

To publish on PyPI on each push to the master branch, you'd need to configure setuptools_scm to produce a version number that PyPI accepts. Currently it's openupgradelib-3.4.2.dev20+g636dcca and the local version identifier part (+g636dcca) will be rejected by PyPI.

But I'd say it's fine for openupgrade to require a fresh version of openupgradelib (installed from git, thus) and do a manual release to PyPI from time to time for faster installation when openupgradelib is used as a dependency of regular addons.

[legalsylvain]

But I'd say it's fine for openupgrade to require a fresh version of openupgradelib (installed from git, thus) and do a manual release to PyPI from time to time for faster installation when openupgradelib is used as a dependency of regular addons.

Makes sense, indeed.

Thanks for your point of view.

[alexis-via]

I was about to open the same issue about release on pypi and found this open ticket. It's really not easy for users for understand the subtle difference between:

• you can get openupgradelib from pypi when your OCA module requires openupgradelib
• you must get openupgradelib from git when you use it for openupgrade

and it goes against the policy of "get all from pypi" that some of you promote !

Since april 2024, openupgrade doesn't work when you use the openupgradelib from pypi and the last release on pypi is dated february 2024.

Why don't we have a system similar to the OCA addons where "ocabot merge minor/major" would bump the version number AND auto-release on pypi ? I guess it would make things easy for maintainers and avoid the problem of "openupgradelib is too old on pypi for openupgrade".

[sbidoul]

I just created 3.7.0. It literally takes 30 seconds here: https://github.com/OCA/openupgradelib/releases/new.

[StefanRijnhart]

@sbidoul Is that picked up by Pypi automatically?

[sbidoul]

@StefanRijnhart Yes there is a publishing workflow that triggers on tags

(When I have a moment, I'll modernize it to use the PyPI trusted publisher workflow)

[alexis-via]

Cool ! Viva openupgradelib 3.7.0 from pypi ! I just switched to it... while I'm in the middle of a big openupgrade migration :) :)

[StefanRijnhart]

@sbidoul Excellent, thanks for clarifying!

[alexis-via]

@sbidoul Thanks for your work on this! I propose to close this issue now.

[legalsylvain]

@sbidoul thanks ! @ all : are we agree to remove reference to master in installation process, and write only openupgradelib (as all the other libraries)