The change to just use open is fine with me.

With this PR, I can build a sdist with just setuptools as here:

./bootstrap sagelib
cd pkgs/sagemath-standard
python -m venv venv_for_sdist
venv_for_sdist/bin/pip install build
venv_for_sdist/bin/pip install setuptools
venv_for_sdist/bin/python -m build -snx

Note that I have to ignore (-x) because the build-dependencies have not been changed (they should, because the build-system requires are supposed to be just what is required to run the build-system; for build wheel requirements see https://peps.python.org/pep-0517/#get-requires-for-build-wheel).

AFAIK setuptools does not support specifying requires-for-build-{sdist,wheel,editable}.

We can of course put our own PEP-517/660 build_meta in there if we really want to.

AFAIK setuptools does not support specifying requires-for-build-{sdist,wheel,editable}.

We can of course put our own PEP-517/660 build_meta in there if we really want to.

See: https://peps.python.org/pep-0517/#get-requires-for-build-wheel and https://peps.python.org/pep-0517/#get-requires-for-build-sdist.

I assume we are aiming for pep-517 build and running setup.py directly is not supported.

And PEP-660 for modern editable.

• sage_setup: Add PEP 517 / PEP 660 buildapi #29845

Can you suggest how to build a sdist without the symlink or the PYTHONPATH hack?

I'll prepare a branch.

That's:

• pkgs/sagemath-standard: Remove self-reference at build time #37292

That's:

* [pkgs/sagemath-standard: Remove self-reference at build time #37292](https://github.com/sagemath/sage/pull/37292)

What is this supposed to fix?

It fixes the "circular reference" that you complained about in #37287 (comment)

Can you suggest how to build a sdist without the symlink or the PYTHONPATH hack?

We seem to be miscommunicating. You build the sdist by making the build requirements declared per PEP-518 available. For example by building wheels of sage-setup and then sagemath-environment in the required versions and making them available for python -m build -s

It fixes the "circular reference" that you complained about in #37287 (comment)

Nothing to do with this PR.

You were about to tell me how to build a sdist of sagemath-standard from the github repo, but instead you've just turned one obstacle (sage-setup) into two (sage-setup + sagemath-environment).

They are not obstacles, they are build dependencies. Where's the difficulty in building them?

They are not obstacles, they are build dependencies. Where's the difficulty in building them?

They are NOT independent. The idea is that build-system dependencies should be readily available so I can, you know, use them to build the package.

Here I cannot modify and build from source if I need to change sage-setup in sync with sagemath-standard because when I try to build sagemath-standard the build frontend will try to build sage-setup from pypi instead of my version.

Documentation preview for this PR (built with commit 487a02f; changes) is ready! 🎉

The idea is that build-system dependencies should be readily available

Whose idea would that be?

Here I cannot modify and build from source if I need to change sage-setup in sync with sagemath-standard because when I try to build sagemath-standard the build frontend will try to build sage-setup from pypi instead of my version.

You already know how to do this. If you don't want to use the venv that is automatically provisioned by build, you make your own venv with the versions that you want to use. Then you run python -m build -nx.

Here I cannot modify and build from source if I need to change sage-setup in sync with sagemath-standard because when I try to build sagemath-standard the build frontend will try to build sage-setup from pypi instead of my version.

You already know how to do this. If you don't want to use the venv that is automatically provisioned by build, you make your own venv with the versions that you want to use. Then you run python -m build -nx.

Have you tried it? As I explained already it doesnt work:

$ python -m build
* Creating venv isolated environment...
* Installing packages in isolated environment... (cypari2 >=2.1.1, cysignals >=1.10.2, cython >=3.0, != 3.0.3, <4.0, gmpy2 ~=2.1.b999, jinja2 >=3.0, jupyter_core >=4.6.3, memory_allocator, numpy >=1.19, pkgconfig, pplpy >=0.8.6, sage-conf ~= 10.3b7, sage-setup ~= 10.3b7, sage_setup[autogen], sagemath-environment ~= 10.3b7, setuptools >= 68.1.1, wheel >=0.36.2)
...
ERROR: Could not find a version that satisfies the requirement sagemath-environment~=10.3b7 (from versions: none)
ERROR: No matching distribution found for sagemath-environment~=10.3b7

Sounds like you need to learn about PIP_FIND_LINKS?

Also: you asked me to remove the symlink,, and I did. I asked politely for an alternative and you just hijacked the issue to push forward completely unrelated stuff.

The idea is that build-system dependencies should be readily available

Whose idea would that be?

PEP-518: "The purpose of this PEP though, is to specify the minimal set of requirements for the build system to simply begin execution."

If you set this PR to "needs review", I'll be happy to set it to "positive review" immediately. It's a simple enough change.

There you go.

If you set this PR to "needs review", I'll be happy to set it to "positive review" immediately. It's a simple enough change.

I "asked for review" in the github interface, but I forgot that even that is NIH.

Yes, we were clearly miscommunicating.

Start from scratch? Feel free to pick a place.

Sounds like you need to learn about PIP_FIND_LINKS?

Can't find it anywhere. If it's a pip thing, let me remind you that we agreed the aim is to pep-517 build, not "pip" build.

Yes, we were clearly miscommunicating.

Start from scratch? Feel free to pick a place.

github issues are definitely not a good place to build a community.

I wish #sagemath would be used, but alas it's not.

I wish #sagemath would be used, but alas it's not.

I can be on Zulip if necessary.

Sounds like you need to learn about PIP_FIND_LINKS?

Can't find it anywhere. If it's a pip thing, let me remind you that we agreed the aim is to pep-517 build, not "pip" build.

PEP-518 does not specify how exactly the declared requirements are to be satisfied.
It is the implementation of the frontend that does.
pypa/build uses pip to provision the declared requirements.
So the environment variables equivalent to pip command-line options can be used to control stuff.

You can see an example of this in https://github.com/sagemath/sage/blob/develop/build/pkgs/sagemath_objects/spkg-install.in