On 12 April 2025 14:33:03 GMT-05:00, Marc Culler <marc.cul...@gmail.com> wrote:
>On Sat, Apr 12, 2025 at 1:01 PM Nils Bruin <nbr...@sfu.ca> wrote:
>
>I get the impression that the concern is about maintenance load: when the
>> project takes on the commitment to build python then it must update the
>> python build package whenever this is required for supporting current
>> operating systems. Apparently that clock ticks very quickly. So that
>> requires frequent updates to the python package.
>>
>
>Not if we follow your suggestion. If your proposed special configure
>option is enabled, which causes Sage to build its own python3 from source,
>then there is one and only one version of python which gets built from
>source -- one which is known to be acceptable to Sage. If that special
>option is not set then Sage does whatever it does to find an acceptable
>python on the system and use it. Those two courses of action are
>completely independent, except that when building from source the spkg must
>build a python3 which is acceptable to Sage. No one should ever be in a
>position where they accidentally trigger the build from source because the
>special "use at your own risk" configure option is required to trigger such
>a build.
>
>Alternatively, the project could set python as a prerequisite and just
>> build on top of that. It shifts what outside clocks we need to keep up
>> with: now we need to ensure that we support a wide enough range of pythons
>> so that it is easy for people to install a python that works on all current
>> operating systems.
>>
>
>When you say "now" you are talking about what Sage already does, not what
>it would have to do if something were changed. Sage *does* support a wide
>range of "system" pythons, which indeed adds a maintenance load and
>restricts which python language features can be used in Sage code.
Marc,
this is what many users need - to be able to install Sage into an existing
Python environment; thus support is provided for a range of pythons.
Catering for the upside-down setup where Sage installs Python is a totally
orthogonal user case, and you seem to be the only user who doesn't want to give
it up.
> The
>alternative (i.e. *always* building a specific python version from source)
>is not something that anyone has suggested. In fact, it is not a crazy
>thing to do, but it would be a departure from what is currently being
>done. I am not proposing that, and certainly no one else would propose
>such a thing.
This is a non-flier for the reasons mentioned above, and previously on this
thread.
>
>I think the main function of having a build-from-source python package was
>> to have a fall-back that allowed us to be very strict with our python
>> requirements. It looks to me that the claim is that nowadays keeping a
>> build-from-source python up to date is more work than keeping up-to-date
>> with the python on which we run.
>>
>
>That claim is contradicted by the fact that upgrading from 3.12.5 to 3.13.3
>required changing 4 lines of text in the spkg. And 3 of the 4 were
>completely obvious.
there is a slew of other related python packages which can just go, once
python3 is gone, e.g. pip with its dependencies, etc. The particular upgrade
you talk about is only easy because other dependencies (some of which could
have been not a part of Sage in the first place) have been updated to
python3.13-compatible state.
Once Sage is 300 or so spkgs lighter, it's much less work to maintain. Just
leave the build and python toolchains, jupyter, etc. maintenance to experts,
and concentrate on the core.
>
>What used to also be the case is that python itself would be quite in flux
>> and that upgrading python from one version to another would need quite a
>> bit of adjustment. I think that was why packaging python was generally
>> deemed beneficial then.
>>
>
>But now that packaging work has been done (and is about to be trashed).
>The amount of new work involved in upgrading the "build from source" part
>of the spkg is trivial, as I just demonstrated. But please do not ignore
>what I said. I did not say that the python3 "build from source" option
>must be maintained forever. I said "Please keep it in place until there is
>a working, tested replacement ." Let me repeat the "Please" part. Please
>don't break our working build system before there is an actual working
>replacement. And, yes, when I say "working" I mean that it works for
>building a self-contained relocatable Sage which can be used for the
>Sage_macOS app.
The working, tested in several ways replacement is there.
The new release isn't terribly close, so macOS app has time to iron out the
kinks.
You even got a PR from Isuru to fix your problems
there.
> The status quo works by that definition. Leaving the
>"build from source" option in place, exactly as it is now, or with the
>addition of the configure option that you proposed, would make it continue
>to work by that definition. What does the Sage project gain by breaking
>our build when the alternative , i.e keeping the "build from source" option
>in place until there is a specific working alternative, has no cost? (And,
>by the way, "people install python somehow" is not a specific working
>alternative. It is not specific, it does not have a working
>implementation, and it is not really an alternative.)
>
>Python has grown considerably and hopefully has turned a lot more stable
>> (and/or distributions have gotten better of supporting older version of
>> python for longer), so it could well be that the calculus has changed on
>> this. That's definitely the position I see Dima and William take.
>>
>> Certainly in the current situation of the python spkg we risk getting the
>> worst of both worlds, if we want to do both well:
>> - we need to ensure that the python spkg actually *can* build python on
>> our supported platforms
>>
>
>Not if the "build from source" route is protected by a special "use at your
>own risk" configure option. Add the "deprecated" tag to the "use at your
>own risk" tag if you like.
>
> - we need to support a wide variety of pythons (including new ones)
>> because people want the python spkg to be happy to have the python
>> prerequisite satisfied by externally provided pythons.
>>
>
>This is not an new risk. This is what you are currently doing. If you
>want to use "system" pythons from a wide range of linux distros then you
>need to support a wide variety of pythons, some of which will be new.
>(Arch linux comes with 3.13 and even has a 3.14 "pre-release" package
>available.)
Distros etc. typically have one previous to current version available too.
E.g. Hombrew has 3.13 and 3.12, Gentoo Linux the same.
On the other hand, as already mentioned, there are external tools such as uv to
get you a venv with a python the version of which the user can choose from a
wide range. In this sense, even if the platform does not have a compatible with
Sage python version natively, such a tool can be used.
Dima
> But no distro would ever use the Sage spkg to build python
>from source anyway. So this really has nothing to do with the topic.
>Nothing being discussed here would remove the existing requirement that
>Sage must support a wide variety of pythons, including new ones.
>
>- Marc
>
--
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/48A8FE7E-AFB3-4057-8BE8-92B41CA09087%40gmail.com.
