On Wed, Apr 09, 2025 at 12:36:59PM -0700, Nils Bruin wrote: > On Wednesday, 9 April 2025 at 12:15:07 UTC-7 dim...@gmail.com wrote: > > >No, this won't fly. This is going to break the already fragile logic > >behind package types. > >Standard packages cannot be optionally installed, so it can't stay > >standard. Optional packages probably cannot appear in toolchain. > > > Presently python3 is a standard package, right? And most of the time the > packages "succeeds" by not installing anything (because prerequisites are > sufficient to provide what is wanted). Standard packages can also fail if > hard prereqs are not met. We can have a standard package python3 that is > simply a stand-in for ensuring that a sufficient python is provided. It > looks like there is a particular scenario where python3 would behave > differently, by actually installing python3 -- namely for building the > MacOS app.
As I already explained, it's quite a stretch by Sage's standards to call
python3 package standard. Because it is not tested enough;
because few months into release, the supposedly stable Sage release is
often not installable, not the least due to rapidly aging Python
toolchain.
As it has been shown here too, already, it's really a very little effort
for macOS app project to switch to an external python toolchain,
they are just stubbonly unwilling to consider this option, saying things
like "don't turn this thread into uv thread". But why not?
They are the only known to us consumer of python3 spkg who depend on it
in a somewhat nontrivial way. I don't want to go into merits of the
macOS app, but it's a highly non-standard by modern Python standards
thing which does not bring to users full functionality of Sage, and ties
them up to a shifty expensive platform.
>
> It sounds to me that Marc is worried that satisfying the python3
> requirement for the MacOS app is going to be fragile if it's not done
> through the standard package route that has been in place since the start
> of sage.
The times where everything, including python, is vendored by Sage, are
long gone. Let's drop the ballast which pulls the project down, and
concentrate on Sage{\bf MATH}, please.
python3 spkg is fragile already, it's a ballast.
Sagelib is teeming with difficult bugs, yet we waste time here.
Do you know how long supposedly standard package brial is essentially broken?
Do you know how many leaks we have in Singular and GAP interfaces?
Do you know that linbox, fflas_ffpack and givaro increasingly look like
abandonware?
Do you know that with each new release of Maxima the number of bugs they
cause in Sage doesn't look like it goes down?
Please look at the bigger picture. Let's assign proper priorities
to tasks ahead. Vendoring python with its toolchain is certainly much
lower priority than the above.
> That's more a confidence/trust issue than a technical issue.
> Hence, providing a smoother transition path may inspire more confidence in
> the participants.
>
> Your stated primary concern about the python3 package was that its attempt
> to build mask other prerequisite deficiencies in the build environment.
> Having a standard python3 package that by default only checks for the
> availability of a sufficient python but that can still build python3 if
> people really want would address your primary concern. So that should count
> as progress for you.
No, not really. Getting rid of python3 spkg is just the 1st step towards
un-vendoring.
Vendoring python and its toolchain should be left to Python experts.
These things should be external to the specialist maths software project like
SageMath.
As long as they are a part of the project, they are ballast making things more
complicated than needed.
>
> At the same time, the concession that python3.spkg *can* still provide
> python if really wanted helps Marc see that the MacOS app build is taken
> seriously. I would expect it's a major delivery platform of sagemath
> functionality to users, so it should be taken seriously.
>
> Quite frankly, things like conda and uv are great initiatives and it would
> be great for sage to work nice with them. Conda is getting quite mature and
> has a wide user base, so transitioning to depending on conda may be a
> reasonable choice. Even if something strange happens to the organization
> behind Conda (those things tend to happen with open source initiatives on a
> fairly regular basis), I think at this point we can be fairly confident
> that it would get forked and remain reasonably supported. With "uv", on the
> other hand, I don't think there's the track record yet to convert to being
> dependent on it without alternatives.
One can more or less do with pip most things you do with uv.
It's just slower, and does not come with an easy to manage built in
venvs.
I won't be worried about uv disappearing, as it's an easy switch to more
usual, older tools.
I would be more worried about going into exclusively Conda direction.
Conda (Conda-forge) is much heavier, as it comes with its own full toolchain,
which is
controlled by Anaconda Inc.
>
> Slow transitions in build architecture decisions in mature projects are a
> feature, not a bug.
We are already late by about 5 or 6 years.
Let's speed up, before we're sunk into obscurity, by Julia/OSCAR, for
instance.
Dima
--
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 sage-devel+unsubscr...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/sage-devel/Z_bvrcs4Iw62QniH%40hilbert.
signature.asc
Description: PGP signature
