On Thursday, December 7, 2023 at 11:06:51 AM UTC-8 Marc Culler wrote: Would it be possible for the sage build process to use sage/local as the unique "system location"?
The sage/local directory would be built by one stage of the sage build process, preceding the stage that builds the venv. That's what `make all-build-local` (or `make all-sage-local`) do. We already use this separation of phases in our portability CI (CI Linux, CI macOS). For Linux, the workflow jobs named "standard-pre" and "minimal-pre" build it and create the Docker images with suffix "-with-targets-pre". See for example https://github.com/sagemath/sage/actions/runs/7108217427/job/19351107432#step:11:4936 For macOS, the workflow jobs named "stage-1" do this. See for example https://github.com/sagemath/sage/actions/runs/7108217428/job/19351098262#step:13:1 The separation into SAGE_LOCAL (which does not contain any Python) and SAGE_VENV makes it possible to build and test different versions or configurations (e.g., --enable-system-site-packages) of Python over the same SAGE_LOCAL. Inside sage/local one would find either files built by the sage build system, or symlinks to files in other locations on the host system, such as /usr/local, or /opt/local, or a conda directory. The question of whether to use a symlink for X would be the same as the question of whether to use "a system-X". That's an interesting proposal. We do have a number of defects in the build system of the Sage distribution, for which something like what you propose could be part of the solution: - the problem that unattended system package updates can break an existing from-source installation of Sage - the problem that switching between from using an SPKG to using a system package is not supported very well (https://github.com/sagemath/sage/issues/29387, https://github.com/sagemath/sage/issues/29708) - the problem that all system packages are collectively represented by the single file SAGE_LOCAL/var/lib/sage/installed/.dummy in our build system - the problem that our own packages do not track dependencies on system packages (https://github.com/sagemath/sage/issues/29711) However, what is not clear to me is whether we can rely on the build systems of the various packages not to resolve the symlinks to the actual installation location. Also pkg-config files (or other package-provided discovery mechanisms) will contain the actual installation location. > The venv would always contain a pyvenv.cfg file. Could you explain why this matters for what you have in mind? -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/16c1d2c7-3230-4e10-9f39-414158d56678n%40googlegroups.com.
