pari-jupyter 1.4.3 release candidate

[Matthias Koeppe]

- https://pypi.org/project/pari-jupyter/1.4.3rc1/

- I've added simple CODE_OF_CONDUCT and CONTRIBUTING files that just point to the main sagemath repository

- using WIP sage-project-cookiecutter to simplify maintenance https://github.com/sagemath/sage/pull/37541

[Edgar Costa]

Bill Allombert has been working on a kernel via xeus:
https://pari.math.u-bordeaux.fr/git/xeus-gp.git/

Which addresses many of the issues with the current one.

While we for its first stable release, I recommend mine: https://github.com/edgarcosta/gp_kernel/

where I have addressed many of the issues, by going through the route that every cell is a temporary file, which is loaded in gp.

--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/e822f186-6504-4516-9940-d03398f270b9n%40googlegroups.com.

[Matthias Koeppe]

Thanks a lot for the pointers, Edgar!

I should point out that I am only doing emergency maintenance of this package; I do not use it myself.

The new release is upstreaming the fix in https://github.com/sagemath/sage/pull/37478.

pari-jupyter has been broken (uninstallable) since Sage 10.2.

[Dima Pasechnik]

I don't see any reason for pari-jupyter being a sage package. It has nothing in common with sagelib, it's a standalone jupyter kernel for Pari-GP.

It has ended up in sage in OpenDreamKit times, to make granting agency happy.

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CA%2BiQ7x5FYigLmaKMc0wodYJB9BUqsdpyuy63RrxXoTcv%2BQKTJw%40mail.gmail.com.

[Marc Culler]

If one has Sage installed with the pari-jupyter package installed in Sage and one wants to run pari-jupyter, what does one do?  Is it equivalent to just installing pari-jupyter with pip and starting it up in the normal way?  Does pari-jupyter use any components of Sage?  If the answers are "yes" and "no", then I agree that it is hard to see any reason why it should be a Sage package.

- Marc

[Dima Pasechnik]

On Fri, Mar 22, 2024 at 3:01 PM Marc Culler <marc....@gmail.com> wrote:

If one has Sage installed with the pari-jupyter package installed in Sage and one wants to run pari-jupyter, what does one do?  Is it equivalent to just installing pari-jupyter with pip and starting it up in the normal way? 

I have pari+libpari installed systemwide. Then  installs pari-jupyter well in a clean python 3.11 venv

Then I can run

    pip install jupyterlab

    jupyter kernelspec install --user $(pwd)/share/jupyter/kernels/pari_jupyter

Then

    jupyter lab

brings up a browser window with all the right notebooks, I can start Pari-GP notebook, etc

 

Does pari-jupyter use any components of Sage?  If the answers are "yes" and "no", then I agree that it is hard to see any reason why it should be a Sage package.

no, I don't think it does. Remove?

Dima

 

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/2648a303-6b46-40d7-8a2e-1eb4f319e7ecn%40googlegroups.com.

[Matthias Koeppe]

Let me just point out that the idea that "grant has ended, so we can kill its deliverables" is fundamentally flawed, and certainly is not and cannot be the position of our project.

Infrastructure grants are exactly set up for their longer-term and broader impacts. 

Matthias

[Marc Culler]

I wasn't advocating anything like that.  Certainly I don't think that pari-jupyter should be "killed".  I am assuming that pari-jupyter is or will be a package that can be installed with pip.  And I am also assuming that it has no direct interaction with Sage.  Are those assumptions wrong?  If not, what benefit does the pari-jupyter project get from having it available as a sage spkg?

A question of more relevance to me is: do I need to add pari-jupyter to the Sage_macOS binary package, even though it could be installed separately by just running pip?  (We try to add all optional packages the we can build.). If installing pari-jupyter creates a kernel specification directory in /usr/local/share (as we do for the Sage kernel), then it will appear as an available kernel when jupyter is launched from the SageMath app, whether or not the location of the kernel is inside the app bundle.  How does it improve our user's experience to have the package installed inside of the app bundle, as opposed to in the user's Library/Python directory or inside the python.org framework?  While this question is specific to me, I think the same question applies to SageMath.

- Marc

[Dima Pasechnik]

On Fri, Mar 22, 2024 at 5:13 PM Matthias Koeppe <matthia...@gmail.com> wrote:

Let me just point out that the idea that "grant has ended, so we can kill its deliverables" is fundamentally flawed, and certainly is not and cannot be the position of our project.

Infrastructure grants are exactly set up for their longer-term and broader impacts. 

the bundling with SageMath was rather artificial in this case, and anyway OpenDreamKit had more deliverables which were not meant to be bundled at all.

Nobody says "kill it".

It's a standalone  PyPI project which does not use anything in SageMath, nor it is used from SageMath.

It can be installed from PyPI if anyone needs it.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/c681d272-5561-4ef9-bdcc-33a1d503cee0n%40googlegroups.com.

[Marc Culler]

By looking at the pari-jupyter page on PYPI I learned that it was written by Jeroen Demeyer and is maintained by the SageMath Developers.  So I guess I don't understand what the relation is between SageMath and pari-jupyter.  Will pari-jupyter be competing with the kernel that Bill Allombert is writing?  Is there a reason why he is writing a kernel when one already exists?  Obviously I have no idea what I am talking about and am publicly revealing my ignorance.

- Marc

[Matthias Koeppe]

10 days ago, the previous maintainer, Vincent Delecroix, announced that he steps down from maintaining it. https://groups.google.com/g/sage-devel/c/fy1ei6bLtmc

I did some emergency maintenance and on that occasion I added the "Maintainers" field in the metadata. Nobody specifically committed to maintaining it or made a plan, as far as I know.

[Nils Bruin]

On Friday 22 March 2024 at 11:22:12 UTC-7 Matthias Koeppe wrote:

10 days ago, the previous maintainer, Vincent Delecroix, announced that he steps down from maintaining it. https://groups.google.com/g/sage-devel/c/fy1ei6bLtmc

I did some emergency maintenance and on that occasion I added the "Maintainers" field in the metadata. Nobody specifically committed to maintaining it or made a plan, as far as I know.

Thanks for that. Obviously, when a maintainer steps down, some follow-up should happen and by the location of the repository, the sagemath community inherits the project in this case by default.

It looks to me like a project that can easily not be offered as an spkg, with minimal effect, but I might be overlooking something. So removing the spkg could make sense.

Judging from the thread here:

https://pari.math.u-bordeaux.fr/archives/pari-dev-2305/msg00002.html

this kernel is very much the basis for whatever Bill is considering. Further down the thread, there is also a reference to Edgar Costa's kernel:

 https://github.com/edgarcosta/gp_kernel

it looks like the discussion there may lead to a new home for the project eventually (or another project to take its place).

[Dima Pasechnik]

On 22 March 2024 19:02:30 GMT, Nils Bruin <nbr...@sfu.ca> wrote:
>On Friday 22 March 2024 at 11:22:12 UTC-7 Matthias Koeppe wrote:
>
>10 days ago, the previous maintainer, Vincent Delecroix, announced that he
>steps down from maintaining it.
>https://groups.google.com/g/sage-devel/c/fy1ei6bLtmc
>I did some emergency maintenance and on that occasion I added the
>"Maintainers" field in the metadata. Nobody specifically committed to
>maintaining it or made a plan, as far as I know.
>
>
>Thanks for that. Obviously, when a maintainer steps down, some follow-up
>should happen and by the location of the repository, the sagemath community
>inherits the project in this case by default.
>
>It looks to me like a project that can easily not be offered as an spkg,
>with minimal effect, but I might be overlooking something. So removing the
>spkg could make sense.

There are also similarly disjoint from Sage packages r-jupyter, singular-jupyter, see
<https://github.com/OpenDreamKit/OpenDreamKit/issues/96>

they can similarly be removed from Sage.
(but mentioned in the docs)

[Matthias Koeppe]

On Friday, March 22, 2024 at 12:02:30 PM UTC-7 Nils Bruin wrote:

It looks to me like a project that can easily not be offered as an spkg, with minimal effect, but I might be overlooking something. 

What you might be overlooking is that 

- our catalog of SPKGs is a useful curation that serves our users;

- our workflows on GH Actions automatically test the packages in our catalog on every release.

[Dima Pasechnik]

I don't think that one would look for e.g. a Jupyter interface to Pari-GP in the catalog of sage spkgs.

The natural place is Pari-GP website.

They are not really "tested" - just as much of the rest of Jupiter stuff is not tested in our CI.
(installability - yes, in a strange non-standard environment, but whether the notebooks actually work, who knows)

pytest has a special plugin, nbmake, to test notebook, and testing notebook kernels/clients ought to involve running actual notebooks on them.

Jupyter interface for Singular seems to be an old beta, and it's just funny to try to offer anything for R, given how big R is compared to Sage.

Let's drop them all from Sage distribution.

[Matthias Koeppe]

On Friday, March 22, 2024 at 3:31:07 PM UTC-7 Dima Pasechnik wrote:

They are not really "tested" - just as much of the rest of Jupiter stuff is not tested in our CI.

(installability - yes, 

 

The installability of it is exactly what was broken in Sage 10.2. 

We test automatically so that we do not have to wait for users' bug reports.

in a strange non-standard environment,

The installability of the package is tested in the relevant environment, namely the Sage venv.

I need to ask you to drop these mischaracterizations of the Sage venv as something "strange" or "non-standard". There's no technical basis for this, and repeating it is harmful to the project. https://groups.google.com/g/sage-devel/c/OeN8o14s6Jc

but whether the notebooks actually work, who knows)

We know because the reviewer of the upgrade ticket https://github.com/sagemath/sage/pull/37478 tested it. 

[Dima Pasechnik]

On 22 March 2024 23:01:47 GMT, Matthias Koeppe <matthia...@gmail.com> wrote:
>On Friday, March 22, 2024 at 3:31:07 PM UTC-7 Dima Pasechnik wrote:
>
>They are not really "tested" - just as much of the rest of Jupiter stuff is
>not tested in our CI.
>
>(installability - yes,
>
>
>The installability of it is exactly what was broken in Sage 10.2.
>We test automatically so that we do not have to wait for users' bug reports.
>
>in a strange non-standard environment,
>
>
>The installability of the package is tested in the relevant environment,
>namely the Sage venv.
>
>I need to ask you to drop these mischaracterizations of the Sage venv as
>something "strange" or "non-standard". There's no technical basis for this,

Of course it is strange and non-standard.
A custom venv, non-standard commands to launch things, pinned to seemingly random values versions of packages, etc.

>and repeating it is harmful to the project.
>https://groups.google.com/g/sage-devel/c/OeN8o14s6Jc
>
>but whether the notebooks actually work, who knows)
>
>
>We know because the reviewer of the upgrade
>ticket https://github.com/sagemath/sage/pull/37478 tested it.

you claimed they are tested by CI, not by humans.


>