Hello;
Has anyone considered making sage as container? This will eliminate all
these issues being discussed here, I would think.
Google AI says this:
"Container-based software delivery packages applications and their
dependencies
into lightweight, isolated environments called containers, enabling
consistent and
reliable deployment across different computing environments"
*"Benefits of Containerization:*
- *Portability:* Containers can run consistently across different
environments, from development to production, without compatibility issues.
- *Efficiency:* Containers are lightweight and resource-efficient,
requiring fewer resources than virtual machines.
- *Scalability:* Containers can be easily scaled up or down, making them
ideal for modern, cloud-native applications.
- *Consistency:* Containerized applications run the same way regardless
of the underlying infrastructure, ensuring consistency across deployments.
"
I do not know if this can work for sage, but it seems to me, sagemath being
a very complicated and advanced
software with many parts with many dependencies, a container type delivery
will be perfect solution.
--Nasser
On Wednesday, April 9, 2025 at 11:21:49 PM UTC-5 dim...@gmail.com wrote:
>
>
> On 9 April 2025 18:54:13 GMT-05:00, Nils Bruin <nbr...@sfu.ca> wrote:
> >On Wednesday, 9 April 2025 at 16:44:31 UTC-7 dim...@gmail.com wrote:
> >
> >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.
> >
> >Are you saying that python source distributions bitrot particularly
> >quickly? Is there something particular about python that breaks their
> >source distributions so quickly? If that's the case, I think that's
> >concerning in itself.
>
> it's not unusual for some "move fast and break things" OS vendors to
> change APIs in incompatible ways, update toolchains in incompatible ways,
> e.g. Apple does it quite often, as we learned over the years. And do not
> forget rolling release OSes.
>
> python (minor) releases come up every 2 months, sometimes every month. I
> gather it's in response to the OS updates, in part.
>
> Our releases are less frequent, and we often don't check that Sage works
> on such and such betas and pre-releases.
>
>
> > It should be possible to build a python source
> >distribution that is a few years old without a problem, right?
>
> no, not really. On some Linux OSes like Debian, some open-source BSDs
> perhaps, on others much less so.
>
> E.g. Apple's XCode update released a short while ago has broken Sage 10.6.
> (as the C++ compiler got a version bump).
>
> Vendors of maths soft should not want to come close to components which
> closely interact with the OS, such as compilers and interpreters, unless
> they just cannot avoid it. In case of Python it's surely beneficial not to
> come close to it, as Python's vendor does a very good job in doing ptompt
> updates, a surely a much better job than our attempts to vendor them.
> Same applies to compilers.
>
>
> > Its
> >prerequisites shouldn't be breaking their APIs on such short timescales.
>
> Tell this to Apple, RedHat (i.e. IBM). :-)
>
> 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/03351ca7-e41b-46b8-beea-0ab36d510a79n%40googlegroups.com.
