Opened 3 years ago

Last modified 8 weeks ago

#21507 new task

Task ticket: Make sagelib a pip-installable Python source package, listed on PyPI — at Version 27

Reported by: mkoeppe Owned by:
Priority: major Milestone: sage-7.6
Component: build Keywords: pip, PyPI
Cc: jdemeyer, was, vbraun, vdelecroix, dimpase, fbissey, embray, leif, aenge, nthiery, mmarco, klee, robertwb, infinity0, thansen, defeo, slelievre, gh-timokau, klui Merged in:
Authors: Reviewers:
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Description (last modified by mkoeppe)

This is a task ticket organizing the steps necessary to eventually provide sagelib via PyPI.

It would be used by a Python user as follows. Let's assume a user has already installed every package that sage-the-distribution provides on their distribution. Then a simple

  pip install sagelib

would install sagelib in the user's Python installation. Then the user could do from sage.all import *.

. . . . . . . . . . . . . . . . .

Here are the first steps:

  • #21508: Clean up src/setup.py to bring it to standard distutils behavior
    • #21480: Make sagelib setup.py self-contained, independent of SAGE_ROOT
    • #21600: Use custom build_ext to compile Cython code
    • #21604: Cleaning up stale installed files in setup()
    • #21654: Disentangle cleaning of stale installed files in build directory and in install directory
    • #21516: Fix sagelib sdist (src/setup.py sdist)
    • #21535: Make src/setup.py respect --build-base and --inplace, independent of SAGE_CYTHONIZED
    • #21573: Make sure src/setup.py respects --install-base and --root
    • #21613: Make setup.py not depend on make
  • #21527: Fix symbolic link to thebe.js
  • #21678: Testsuite for src/setup.py
  • #20108: Use package_data instead of data_files in setup.py
  • #21682: Add a separate "cythonize" command to setup.py
  • #21569: Install src/bin/* scripts via setup.py (scripts, console_scripts)
  • #21570: Move non-scripts of src/bin/ elsewhere (and also move their install location)
  • #21571: Install COPYING.txt in SAGE_LOCAL and use it from misc/copying.py
  • #21509: Install cython_debug somewhere in SAGE_LOCAL

This defines milestone 1. sagelib is now a well-behaved Python package. It can be built and installed as follows (without invoking sage -sh):

export SAGE_LOCAL=/path/to/local/hierarchy/populated/by/sage/distribution
export SAGE_PKGS=/path/to/sage/distribution/source/directory/build/pkgs
$SAGE_LOCAL/bin/python setup.py install   # or pip install . 

. . . . . . . . . . . . . . . . .

Next steps:

  • Remove the dependency on the environment variable SAGE_PKGS (#20382, ...)

This defines milestone 2. sagelib can now be built and installed as follows (without invoking sage -sh):

export SAGE_LOCAL=/path/to/local/hierarchy/populated/by/sage/distribution
$SAGE_LOCAL/bin/python setup.py install   # or pip install . 

. . . . . . . . . . . . . . . . .

Next steps:

  • Remove the dependency on the SAGE_LOCAL environment variable
    • #15105: hardwired paths in src/sage
    • ...

This defines milestone 3. If SAGE_LOCAL is not set, then sagelib will discover system packages and Python packages installed in standard places.

python setup.py install   # or pip install . 

At this point, sagelib will be a standard pip-installable Python source package, ready for upload to PyPI.

Binary packages (using wheels etc.) is beyond the scope of this ticket.

Change History (27)

comment:1 Changed 3 years ago by mkoeppe

  • Cc was vbraun vdelecroix dimpase added
  • Description modified (diff)

comment:2 Changed 3 years ago by mkoeppe

  • Cc fbissey embray leif added
  • Description modified (diff)

comment:3 Changed 3 years ago by mkoeppe

  • Description modified (diff)

comment:4 Changed 3 years ago by mkoeppe

  • Milestone changed from sage-7.4 to sage-7.5

comment:5 Changed 3 years ago by mkoeppe

  • Description modified (diff)

comment:6 Changed 3 years ago by mkoeppe

  • Description modified (diff)

comment:7 Changed 3 years ago by mkoeppe

  • Description modified (diff)

comment:8 Changed 3 years ago by mkoeppe

  • Cc aenge nthiery added

comment:9 Changed 3 years ago by mkoeppe

  • Cc mmarco klee robertwb added

comment:10 follow-up: Changed 3 years ago by embray

Thanks for taking the lead on this. There's more still be to added to the list of issues, such as providing binary wheels and how that will be handled. I think it will be important to also make more progress on making some hard dependencies optional (that is, allow optional features to fail gracefully if a dependency for that feature is not found).

comment:11 in reply to: ↑ 10 Changed 3 years ago by mkoeppe

Replying to embray:

There's more still be to added to the list of issues, such as providing binary wheels and how that will be handled.

Definitely. I'm hoping that we can use this ticket to organize it.

I think it will be important to also make more progress on making some hard dependencies optional (that is, allow optional features to fail gracefully if a dependency for that feature is not found).

I agree.

comment:12 Changed 3 years ago by mkoeppe

Here's a question for the distutils experts. Is a Python package allowed to install things in bin/? Do any other Python packages do that? Where would one install helper scripts? Is there a Python equivalent of $prefix/libexec?

comment:13 Changed 3 years ago by mkoeppe

  • Description modified (diff)

comment:14 Changed 3 years ago by was

This Python package, which is part of SMC, installs many things to /usr/local/bin using completely standard approaches: https://github.com/sagemathinc/smc/tree/master/src/smc_pyutil. See, in particular, the console_scripts section of setup.py: https://github.com/sagemathinc/smc/blob/master/src/smc_pyutil/setup.py#L58

comment:15 Changed 3 years ago by mkoeppe

Thanks a lot! Following your pointer, I've found this documentation: http://python-packaging.readthedocs.io/en/latest/command-line-scripts.html, which I will refer to alongside the example that you pointed out.

comment:16 Changed 3 years ago by mkoeppe

  • Description modified (diff)

comment:17 Changed 3 years ago by mkoeppe

This now #21569.

comment:18 Changed 3 years ago by mkoeppe

  • Description modified (diff)

comment:19 Changed 3 years ago by mkoeppe

  • Description modified (diff)

comment:20 Changed 3 years ago by mkoeppe

  • Description modified (diff)

comment:21 follow-up: Changed 3 years ago by embray

I don't like the phrasing "PyPI package". There's no such thing as a "PyPI package" per se. Let's be more clear about what we want here--should it be buildable from a source package? Or are we providing binary wheels? Both? Neither?

comment:22 follow-up: Changed 3 years ago by embray

I wonder if this work might not also benefit from adopting portions of astropy-helpers into Sage's build tools. I don't think it would necessarily be appropriate to use directly--although there's nothing very "astropy" specific in astropy-helpers, a lot of it does assume one is using the astropy project template, or something close to it. But large swaths of it are very generic, and I put a lot of work into developing tools for build sanity of large Python projects.

Some key features that I think might benefit sage include:

  • per-subpackage setup_package.py modules, which can contain any number of a (mostly) well-documented hooks for building compiled modules in that sub-package. This provides a clear and explicit alternative to a monolithic module_list.py (see the discussion here), and would also make it easier to break off some of Sage's subpackages into standalone packages should the time ever come for that.
  • one of the less-well-documented features is also that setup_package.py can contain hooks for setup.py commands. For example, if a module contains some generated code (a la sage_setup.autogen), it can include a pre_build_ext hook to make sure the generated code is up to date before running the ./setup.py build_ext command (either explicitly, or implicitly as a sub-command). This makes it relatively easy for individual submodules to put hooks into the build process without having to write complicated command subclasses cluttered with subpackage-specific crud.
  • smarter handling of Cython modules--for example, when creating a source tarball it will make sure all Cython modules have been Cythonized, and it will include the resulting C/C++ sources in the source tarball. This ensures that the user does not need Cython to be installed in order to build from source (which is good, because even if they do have Cython it will often be the wrong version--and in Sage's case missing important patches as well).

Those are the main ones for now but I could probably think of more.

comment:23 in reply to: ↑ 21 Changed 3 years ago by mkoeppe

Replying to embray:

I don't like the phrasing "PyPI package". There's no such thing as a "PyPI package" per se. Let's be more clear about what we want here--should it be buildable from a source package? Or are we providing binary wheels? Both? Neither?

The scope of this ticket is a source package that is pip-installable and would be listed as such on PyPI.

Binary packaging (about which I don't know anything at the moment) is beyond the scope of this ticket.

comment:24 in reply to: ↑ 22 Changed 3 years ago by mkoeppe

Replying to embray:

I wonder if this work might not also benefit from adopting portions of astropy-helpers into Sage's build tools.

This all sounds great and seems like it could be part of #21508 or be a follow up to it.

comment:25 Changed 3 years ago by mkoeppe

  • Description modified (diff)
  • Summary changed from Make sagelib a PyPI package to Make sagelib a pip-installable Python source package, listed on PyPI

I've updated the description to explain the scope of the ticket better.

comment:26 Changed 3 years ago by mkoeppe

  • Description modified (diff)
  • Summary changed from Make sagelib a pip-installable Python source package, listed on PyPI to Task ticket: Make sagelib a pip-installable Python source package, listed on PyPI

comment:27 Changed 3 years ago by mkoeppe

  • Description modified (diff)
Note: See TracTickets for help on using tickets.