For most of the packages, there is no explicit version tracking. On
the current rather small list only ore_algebra has an explicit
reference to a commit in requirements.txt

$ cat admcycles/requirements.txt
admcycles

$ cat surface_dynamics/requirements.txt
surface_dynamics

$ cat ore_algebra/requirements.txt
git+https://github.com/mkauers/ore_algebra@6826ac49b4cdf66a563449aced21a2fd1fd085c9#egg=ore_algebra

If instead ore_algebra would properly release on PyPI, the
sage side of things would be simpler.

Best
Vincent

PS: still there is the issue of "old" SageMath versions that might
not be compatible with "recent" package versions. The only mechanism
is to tight a single version of a package to a SageMath version as it
was done with ore_algebra. The latter is quite restrictive given that
packges might evolve between two sage releases.

Le 08/02/2021 à 13:06, Thierry a écrit :
Hi,

On Sun, Feb 07, 2021 at 04:49:23PM -0800, Matthias Koeppe wrote:
The first few user packages have been added in 9.3.beta7:
ore_algebra, sage_flatsurf, admcycles, slabbe, surface_dynamics.

We should notice that, contrary to other packages, those packages should
be considered as downstream (not upstream), and this should be reflected
in our release process.

Indeed, their code get adapted after Sage changes, see e.g. (randomly
chosen examples):

https://github.com/mkauers/ore_algebra/commit/2d71b50ebad81e62432482facfe3f78cc4961c4f
https://github.com/mkauers/ore_algebra/commit/8c678f9c70aee8df211c04211dd2f7e230a4770f

For upstream packages (especially important ones), they should usually
be merged in the beginning of a new release (on beta[n] with small n),
so that incompatibilities could be reported and fixed before the
official release.

In the current case, it should be the opposite, after downstream adapted
their code to our changes, so that those packages are not broken for the
official release.

Hence, there should be a way to update the versions of such packages
during beta[-1] (the one before rc0), at least those packages should be
tagged "downstream" somewhere (e.g.  whithin SPKG.rst file or whatever),
so that someone could have a look before the rc.

While our naming of development releases is pretty poor (beta or rc), we
should perhaps indicate somewhere which intervals are reserved for
backward-incompatible changes, and so on.

Another question: what happens if at the end of a Sage release cycle,
the downstream package is still broken ? Shall we remove the package
from build/pkgs ? Shall we add a temporary patch within the spkg
directory ? Or add a "broken" keyword for the "type" file ?

Ciao,
Thierry


On Wednesday, January 13, 2021 at 7:41:48 PM UTC-8 Matthias Koeppe wrote:

Meta-ticket https://trac.sagemath.org/ticket/31164 proposes to add user
packages, such as those listed at
https://wiki.sagemath.org/SageMathExternalPackages, to the Sage
distribution as "pip" packages. This has the following benefits:

    - They will be automatically included in our reference manual and Sage
    website (https://trac.sagemath.org/ticket/29655).
    - We have GitHub Actions workflows in place
    (tox-optional.yml, tox-experimental.yml), which will automatically try to
    build the packages on each beta release. This provides continuous
    integration that will allow us to catch unintended breaking changes during
    the Sage development cycle.

Help is needed with this task.
- If a package listed at
https://wiki.sagemath.org/SageMathExternalPackages is outdated (does not
work with a current version of Sage), it will be helpful to add a note to
the wiki page and to notify the package authors.
- If a package seems to work with current Sage, help by creating a ticket
for the inclusion in Sage and list the ticket in meta-ticket
https://trac.sagemath.org/ticket/31164
- If a significant package is neither listed in build/pkgs/ nor in the
wiki page, please add it.







--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/88ba0229-2e6f-4a04-a955-157248c5f90bn%40googlegroups.com.


--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/b467c19d-ad98-2c57-4e56-a35d7bf5f7eb%40gmail.com.

Reply via email to