Isn't there a way that we do not put the burden on the user?

Can't we do something like:

[project.optional-dependencies]
passagemath = [
  'passagemath-environment',
  'passagemath-flint',
  'passagemath-modules',
  ]

?

In the monolithic Sage, building with build isolation is just not possible because you cannot just install a copy of Sage during the build phase; that's the very design bug of Sage that passagemath fixes.

I understand that is a problem, but if the users already has a flavor of sage, we should not be mixing and matching flavors without need.

if the users already has a flavor of sage, we should not be mixing and matching flavors without need.

Obviously, which is why users need to use --no-build-isolation.

There's no way around educating users about the fact that the use of monolithic Sage is in conflict to standard practices in Python.

Can't we do

[project.optional-dependencies]
passagemath = [
  'passagemath-environment',
  'passagemath-flint',
  'passagemath-modules',
  ]

?

Can't we do something like:

[project.optional-dependencies]
passagemath = [

These are run-time dependencies, not build-time dependencies.

(Such optional run-time dependencies are already declared in setup.py ("extras_require").)

By the way, in a conda environment, users have the same "burden" to know about --no-build-isolation to make sure that the installed conda packages rather than automatically provisioned pip packages are used during the build phase.
So this burden is not unusual in the Python world.

My struggle is that #105 is not backwards compatible.
Before #105 you would install this package via

sage -pip install (--user) git+https://github.com/mkauers/ore_algebra.git

which implicitly implies that you need to have a working version of sage.

After #105, the default installation process will lead to edgarcosta#1, and thus users should use instead:

sage -pip install (--user) --no-build-isolation git+https://github.com/mkauers/ore_algebra.git 

I understand that now I am supposed to do (I can't, see below, and also note the different command from the README)

python3 -m venv venv_ore_algebra
. venv_ore_algebra/bin/activate
pip install "ore_algebra[passagemath] @ git+https://github.com/mkauers/ore_algebra.git"

but if this is the goal, wouldn't be easier to have a meta package for this that could be even be easily published on PyPI?
And thus partially tackle #19, which I don't think it can be tackled with other flavors of sage.

Here is the traceback:

      In file included from src/ore_algebra/analytic/binary_splitting_arb.cpp:1164:
      /tmp/pip-build-env-fpd4keed/overlay/lib/python3.10/site-packages/sage/libs/flint/flint_wrap.h:39:10: fatal error: flint/flint.h: No such file or directory
         39 | #include <flint/flint.h>
            |          ^~~~~~~~~~~~~~~
      compilation terminate
      ```

users should use instead:

sage -pip install (--user) --no-build-isolation git+https://github.com/mkauers/ore_algebra.git 

Yes. Not as a "fallback", but just as what you document users to do.

About publishing to PyPI, are you talking source distribution or binary distribution?

Here is the traceback:

      In file included from src/ore_algebra/analytic/binary_splitting_arb.cpp:1164:
      /tmp/pip-build-env-fpd4keed/overlay/lib/python3.10/site-packages/sage/libs/flint/flint_wrap.h:39:10: fatal error: flint/flint.h: No such file or directory
         39 | #include <flint/flint.h>
            |          ^~~~~~~~~~~~~~~
      compilation terminate

That's normal. You build stuff from source, so you need the non-Python dependencies in your system. There's nothing in Python packaging that takes care of non-Python dependencies.

If you are interested in publishing binary wheels of ore_algebra using passagemath to PyPI, then yes, that's straightforward to do. I can send you a PR with the GH Actions scripts that I use for other packages (example: https://github.com/passagemath/passagemath-primesieve-primecount/blob/passagemath/.github/workflows/dist.yml)

wouldn't be easier to have a meta package for this

No, there's no such thing in modern Python packaging as a package that takes control over how another package is built.

users should use instead:

sage -pip install (--user) --no-build-isolation git+https://github.com/mkauers/ore_algebra.git 

Yes. Not as a "fallback", but just as what you document users to do.

I remember that you suggested that in #105 (comment), and I think it worked for me at the time, but it no longer does. I don't know what has changed. (This is with Sage 10.8.beta0.)

$ sage -pip install --no-build-isolation git+https://github.com/mkauers/ore_algebra.git
Collecting git+https://github.com/mkauers/ore_algebra.git
  Cloning https://github.com/mkauers/ore_algebra.git to /tmp/pip-req-build-j9kcaqxi
  Running command git clone --filter=blob:none --quiet https://github.com/mkauers/ore_algebra.git /tmp/pip-req-build-j9kcaqxi
  Resolved https://github.com/mkauers/ore_algebra.git to commit 4f463b4f9b18f5c6f5ad2af0bc4378aeae83a5fa
  Preparing metadata (pyproject.toml) ... error
  error: subprocess-exited-with-error

  × Preparing metadata (pyproject.toml) did not run successfully.
  │ exit code: 1
  ╰─> [1596 lines of output]

      Error compiling Cython file:
      ------------------------------------------------------------
      ...
      # Distributed under the terms of the GNU General Public License (GPL) either
      # version 2, or (at your option) any later version
      #
      # http://www.gnu.org/licenses/

      from sage.libs.arb.types cimport *
      ^
      ------------------------------------------------------------

      src/ore_algebra/analytic/binary_splitting_arb.pyx:17:0: 'sage/libs/arb/types.pxd' not found

@mkoeppe one could have two packages: ore_algebra and ore_algebra-passagemath.

Regardless, in the current setup there is one pyproject.toml, and we cannot do conditionals, thus one of the two groups of users needs to add --no-build-isolation to ignore the decencies there.
I don't understand why we are breaking backwards compatibility for the people that have been doing sage -pip install, when the users that want to use ore_algebra in a virtual Python environment (no SageMath installation required) could do something like:

python3 -m venv venv_ore_algebra
. venv_ore_algebra/bin/activate
pip install pkgconfig passagemath-{environment,flint,modules}
pip install git+https://github.com/mkauers/ore_algebra.git --no-build-isolation

@edgarcosta This is how progress works. "One small step for ore_algebra, one giant leap for sagekind".

(This is with Sage 10.8.beta0.)

$ sage -pip install --no-build-isolation git+https://github.com/mkauers/ore_algebra.git
Collecting git+https://github.com/mkauers/ore_algebra.git
  Cloning https://github.com/mkauers/ore_algebra.git to /tmp/pip-req-build-j9kcaqxi
  Running command git clone --filter=blob:none --quiet https://github.com/mkauers/ore_algebra.git /tmp/pip-req-build-j9kcaqxi
  Resolved https://github.com/mkauers/ore_algebra.git to commit 4f463b4f9b18f5c6f5ad2af0bc4378aeae83a5fa
  Preparing metadata (pyproject.toml) ... error
  error: subprocess-exited-with-error

  × Preparing metadata (pyproject.toml) did not run successfully.
  │ exit code: 1
  ╰─> [1596 lines of output]

      Error compiling Cython file:
      ------------------------------------------------------------
      ...
      # Distributed under the terms of the GNU General Public License (GPL) either
      # version 2, or (at your option) any later version
      #
      # http://www.gnu.org/licenses/

      from sage.libs.arb.types cimport *
      ^
      ------------------------------------------------------------

      src/ore_algebra/analytic/binary_splitting_arb.pyx:17:0: 'sage/libs/arb/types.pxd' not found

This failure has nothing to do with pyproject.toml or --no-build-isolation.

Complain to the people who have been making wild changes in Sage lately.

Regardless, in the current setup there is one pyproject.toml, and we cannot do conditionals, thus one of the two groups of users needs to add --no-build-isolation to ignore the decencies there.

It's not even about "conditionals in dependencies".

Build isolation is the new default for Python packaging -- per a standard that will celebrate its 10th birthday next month: https://peps.python.org/pep-0517/

That projects without a pyproject.toml can still be built at all is purely legacy behavior, which could disappear any time really now.

From: https://packaging.python.org/en/latest/discussions/setup-py-deprecated/ :

Is setup.py deprecated?

No, setup.py and Setuptools are not deprecated.

Setuptools is perfectly usable as a build backend for packaging Python projects. And setup.py is a valid configuration file for Setuptools that happens to be written in Python, instead of in TOML for example (a similar practice is used by other tools like nox and its noxfile.py configuration file, or pytest and conftest.py).

No, setup.py is not deprecated. Your point?

@edgarcosta For your reading list: https://peps.python.org/pep-0518/

The current python documentation doesn't seem to imply at all that:

That projects without a pyproject.toml can still be built at all is purely legacy behavior, which could disappear any time really now.

Anyhoo, my point is the same, there seem to be two solutions:

1. Update "With Sage built from source or binaries from sagemath.org"

sage -pip install (--user) --no-build-isolation git+https://github.com/mkauers/ore_algebra.git 

2. Revert parts of Support use with the modularized passagemath distributions #105 and update "Using ore_algebra in a virtual Python environment (no SageMath installation required) ":

python3 -m venv venv_ore_algebra
. venv_ore_algebra/bin/activate
pip install pkgconfig passagemath-{environment,flint,modules}
pip install git+https://github.com/mkauers/ore_algebra.git --no-build-isolation

I would say that as we speak, most users fall under the category of "With Sage built from source or binaries from sagemath.org," and therefore, it is advisable not to break backward compatibility. I understand that your goal is to lower the entry barrier to using Sage, but this approach does not achieve that. Instead, #105 increases the entry barrier to using this package.

The current python documentation doesn't seem to imply at all that:

It does not? You'll at least have to tell me what you have read; this is just disrespectful.

@mkoeppe #139 (comment)

Like I said, it's correct that setup.py is not deprecated. But this random fact has nothing to do with the discussion.

(You'll notice that #105 did not remove the use of setup.py, or of setuptools.)

@mezzarobba I wrote:

      src/ore_algebra/analytic/binary_splitting_arb.pyx:17:0: 'sage/libs/arb/types.pxd' not found

This failure has nothing to do with pyproject.toml or --no-build-isolation.

Complain to the people who have been making wild changes in Sage lately.

I see that you have now brought this to the attention of sage-devel.

I'll note that the same people who blame a "test being too weak" (https://groups.google.com/g/sage-devel/c/dqKGLT8EeB8/m/yAhqu-HsBAAJ) for not discovering this breakage are the same who vandalized the infrastructure that I built for integration testing of optional packages -- including ore_algebra.

See:

• Continued vandalism in the SageMath project passagemath/passagemath#1508 (comment)