Moving base environment to 3.12?

fbraun4358 commented 4 weeks ago

Comment:

I was wondering if there are plans to move the base environment miniforge ships with the 3.12 any time soon.

miniconda is already defaulting to 3.12 if you just grab the latest version without specifying a python version. miniforge is still defaulting to 3.10

While it is easy to spin up new environments, it would be nice to have the base environment also be 3.12. Selfishly this is question is coming because my work has implemented an N-1 policy, so only latest version and -1 is allowed for Python, even though 3.10 is still getting security fixes

jakirkham commented 4 weeks ago

Users can update the python in base. Did you try this already?

hmaarrfk commented 4 weeks ago

ps. you have to force it with

conda install python=3.12

fbraun4358 commented 4 weeks ago

Yeah, I know we can do that. The issue our internal security folks have is that the installer will install python 3.10 to begin with. From their stand point, being able to update is not enough, it needs to ship with at last 3.11. Why they have this in their mind, don't ask me. 3.10 is still a perfectly supported python version with security fixes.

I guess my question is if it is possible/likely to publish to publish both 3.10 and 3.12 versions, the same way miniconda publishes conda alongside multiple different python versions? And just in general if you have any road map in mind for updating the base python version.

hmaarrfk commented 4 weeks ago

It isn't likely that we will publish both. It is alot of maintenance work to do both. But..... We might be updating soon.

The thing is. That open source software definitely won't move at your pace. If y9u r security folk want something. Just build your own installers (use the scripts here and change 3.10 to 3.12) and put them on your company shared drive for your internal use case.

But..... I have been thinking of updating the bad version and while 3.12 might be ambitious. But we recently soft closed 3.12 migration do it may be fine

https://github.com/conda-forge/conda-forge-pinning-feedstock/pull/5851

jakirkham commented 4 weeks ago

Would be interested to hear more about the reasoning if possible (which it might not be)

Imagine there are other folks who don't let us know (as you have kindly done) about issues like this. So getting more insight from them on the issues as they see them would improve the discussion quality and let us reach better outcomes

For example when looking at Python version support, am seeing 3.10 gets security updates until October 2026. So naively would think this is good enough. What is missed in this reasoning?

fbraun4358 commented 4 weeks ago

The larger company I work for has had > 2 well publicized data breach/security incident in the last 18 months. RCA on these has shown a total cultural lack for security mindedness. To improve things, corporate policies have been updated that all things must:

Run on still supported versions of languages, frameworks, libraries, etc.
- Only running on LTS versions of language which have such a concept, think Java and C#
- Keeping libraries up to date, etc.
When having a Language with multiple LTS versions, like Java with 21, 17, 8 etc, the only acceptable LTS versions are N and N-1
- For Java this would be 21 and 17 for instance
- For python, since there isn't really "LTS" just support, the N and N-1 have been decided to mean current Python and the last release.

I don't really have insight into why this reasoning exists, just that it does. I think for python the idea is essentially "Always be on the latest version, and when a new version comes out, you have some grace period to update". Essentially you have year to get to the latest version.

Now, I personally have very many opinions on this... especially given how long it sometimes takes large python libs, especially in the ML space to be compatible with the latest versions.

Now, from a miniforge position, I totally understand shipping miniforge with the conda-froge "default". If most of the conda-forge packages don't work with 3.12, shipping 3.12 as the base it can cause confusion. At the same time, since miniforge is just an absolutely minimal install of conda, with no conda packages actually installed, I can see the argument for shipping miniforge with the latest python and then saying "you need to create new environments". I don't know how most people actually use conda, but for us, nothing ever gets added to base. everything is a new environment.

@hmaarrfk I will look into building our own installer based off of 3.12. I have been looking at the files and I am failing to understand how the construct and build shell files work together. I have to build a windows installer, so trying to figure out what I need locally to build the installer.

hmaarrfk commented 4 weeks ago

Thanks for the insights.

for what its worth i'm putting it to a vote and hopefully it can be resolved by July: https://github.com/conda-forge/miniforge/issues/598

Thank you for understanding why we sometimes stick a few versions back. Honestly, there has been alot of churn on other packages, so ensuring this one is "working" has been a strong base for us in genera.

Sigh, you are concerned about windows. The crazy thing there is that we posix to build it.

see https://github.com/conda-forge/miniforge/blob/main/build_miniforge_win.sh as a starting point

conda-forge / miniforge

Moving base environment to 3.12? #597

Comment: