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

[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
  • #12659: build the sage library in place
  • #21573: Make sure src/setup.py respects --install-base and --root
  • #21613: Make setup.py not depend on make (follow-up: #22044, #22094, #22106)
  • #22061: Don't hard-code the path to thebe.js (dup: #21527: Fix symbolic link to thebe.js)
• #21678: Testsuite for src/setup.py
• #21785: Installation of SAGE_SRC/ext/ in SAGE_LOCAL/share/sage/ext/ should be done by setup.py, not build/make/Makefile
• #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
• #21732: Move runtime documentation python modules into src/sage

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
  • #21803: env.py, misc/cython.py: Define and use FLINT_INCLUDE_DIR
  • ...

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.

. . . . . . . . . . . . . . References . . . . . . . . . . . . . . .

• ​https://docs.python.org/2/library/distutils.html
• ​https://setuptools.readthedocs.io/en/latest/setuptools.html#command-reference
• ​https://docs.python.org/2/distutils/sourcedist.html
• ​https://docs.python.org/2/install/
• ​https://pip.pypa.io/en/stable/reference/pip_install/#pip-install-examples
• ​http://askubuntu.com/questions/802544/is-sudo-pip-install-still-a-broken-practice
• ​http://stackoverflow.com/questions/33004708/osx-el-capitan-sudo-pip-install-oserror-errno-1-operation-not-permitted/33004920#33004920
• ​https://packaging.python.org/science/
• ​https://packaging.python.org/current/
• ​https://packaging.python.org/key_projects/#setuptools
• ​https://setuptools.readthedocs.io/en/latest/setuptools.html#development-mode
• ​https://www.cac.cornell.edu/wiki/index.php?title=Python_Distutils_Tips
• ​https://blog.ionelmc.ro/2014/05/25/python-packaging/
• ​http://stackoverflow.com/questions/7522250/how-to-include-package-data-with-setuptools-distribute

[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).

[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.

[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?

[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

[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.

[mkoeppe]

This now #21569.

[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?

[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.

[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.

[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.

[mkoeppe]

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

[fbissey]

I have a request: currently the sage kernel for jupyter is created directly in place on the file system rather than being "installed". Similarly there are 3 links created by the jupyter kernel installation. That's not ideal from a distro point of view, and I am not sure that's acceptable from pip point of view.

[jdemeyer]

Replying to fbissey:

That's not ideal from a distro point of view, and I am not sure that's acceptable from pip point of view.

Can you elaborate why that is an issue?

[fbissey]

Very simple. From a distro point of view (and good build system), you only build in a sandbox isolated from the main system. Then you stage your installation, if you are using autotools, by using DESTDIR, if using setup.py usually with --root. At no point you do something to the live system before the "merge", moving the staged install to the live file system.

I know we had some discussion when the current mechanic has been put in place as part of the install phase, unfortunately it doesn't obey --root. I will run a new check since it's been a while since I hit this.

Prior to 7.5.beta0 I have been patching to build kernel.json and then install it with python_package_data. I have decided that the patching to setup.py would be to invasive now and currently in 7.5.beta0+ I install manually at the package manager level.

[jdemeyer]

Replying to fbissey:

Very simple. From a distro point of view (and good build system), you only build in a sandbox isolated from the main system. Then you stage your installation, if you are using autotools, by using DESTDIR, if using setup.py usually with --root. At no point you do something to the live system before the "merge", moving the staged install to the live file system.

I know we had some discussion when the current mechanic has been put in place as part of the install phase, unfortunately it doesn't obey --root. I will run a new check since it's been a while since I hit this.

Prior to 7.5.beta0 I have been patching to build kernel.json and then install it with python_package_data. I have decided that the patching to setup.py would be to invasive now and currently in 7.5.beta0+ I install manually at the package manager level.

Sorry, but I don't see how the above is an answer to my question.

[jdemeyer]

...or maybe the problem is that the kernel spec is generated during the install phase.

Then the problem is not the fact that it is generated, but when it is generated.

[jdemeyer]

Replying to fbissey:

Very simple. From a distro point of view (and good build system), you only build in a sandbox isolated from the main system. Then you stage your installation, if you are using autotools, by using DESTDIR, if using setup.py usually with --root.

Just to make me understand better, what are the commands that you would typically run to install a Python package this way?

[fbissey]

Would be worse during the build phase

        self.kernel_dir = os.path.join(JUPYTER_PATH, "kernels", self.identifier())

that's straight on the file system.

For the installation, instead of just doing python setup.py install you do python setup.py install --root=$DESTDIR. It's supposed to do the same thing than using DESTDIR in autotool, everything will be installed as it normally should except that all the paths will be prefixed with DESTDIR.

[jdemeyer]

Replying to fbissey:

For the installation, instead of just doing python setup.py install you do python setup.py install --root=$DESTDIR.

And why does it make a difference then whether the kernel spec files are generated or copied during that install step? I am a bit lost here...

[fbissey]

The problem is that it created directly on the file system rather than in DESTDIR, not a problem for sage the distribution but a pain in the ass for the other people

>>> Install sage-9999 into /scratch2/portage/sci-mathematics/sage-9999/image/ category sci-mathematics
 * python2_7: running distutils-r1_run_phase distutils-r1_python_install
/usr/bin/python2.7 setup.py install --root=/scratch2/portage/sci-mathematics/sage-9999/image/_python2.7
make: Nothing to be done for 'all'.
....
....
byte-compiling /scratch2/portage/sci-mathematics/sage-9999/image/_python2.7/usr/lib64/python2.7/site-packages/sage/structure/all.py to all.pyc
writing byte-compilation script '/scratch2/portage/sci-mathematics/sage-9999/temp/tmpoErZMu.py'
/usr/bin/python2.7 -OO /scratch2/portage/sci-mathematics/sage-9999/temp/tmpoErZMu.py
removing /scratch2/portage/sci-mathematics/sage-9999/temp/tmpoErZMu.py
running install_egg_info
Writing /scratch2/portage/sci-mathematics/sage-9999/image/_python2.7/usr/lib64/python2.7/site-packages/sage-9999-py2.7.egg-info
error: [Errno 13] Permission denied: '/usr/share/jupyter/kernels/sagemath/kernel.json'

The correct jargon for this is "sandbox violation", the build process is not supposed to write on the live file system at this stage.

[jdemeyer]

In that case, I would prefer to fix the problem by generating the files in the correct place. That should not be so hard, feel free to create a ticket for that.

[fbissey]

I wish, --root is not very well documented as far as I can see. DESTDIR is quite easy we know the variable name. I am not sure there is a real equivalent variable for setup.py, otherwise I would have filled a trivial ticket long ago. I'll look again.

[embray]

I think the distinction of when or how the file is generated is mostly irrelevant, but fbissey is right that it should be generated in the right location, and not directly to JUPYTER_PATH.

[fbissey]

Replying to embray:

I think the distinction of when or how the file is generated is mostly irrelevant, but fbissey is right that it should be generated in the right location, and not directly to JUPYTER_PATH.

That would be OK if it was done relative to the argument of --root, you wouldn't know how to get to that Erik? I meant to look it up deeper but stuff is piling on me.

[embray]

Yeah, I'd be willing to look into it. There should maybe be yet another ticket opened specifically for this issue.