Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enforcing system requirements - Miniforge3 Blocker #614

Closed
jaimergp opened this issue Jul 24, 2024 · 11 comments · Fixed by #626
Closed

Enforcing system requirements - Miniforge3 Blocker #614

jaimergp opened this issue Jul 24, 2024 · 11 comments · Fixed by #626

Comments

@jaimergp
Copy link
Member

I noticed that we are documenting now our base system requirements. constructor right now won't do much to enforce it though. I've opened conda/constructor#809 to deal with this upstream but it hasn't landed yet (needs review).

When it does land, we should probably add this to construct.yaml so the installer fails to start:

virtual_specs:
  - __glibc >=2.17  # [linux]
  - __osx >=10.13   # [osx]
@isuruf
Copy link
Member

isuruf commented Jul 24, 2024

So, are we going to keep making micromamba and conda-standalone with the older glibc versions? Otherwise that CONDA_EXEC call is going to crash without a useful message.

@hmaarrfk
Copy link
Contributor

Note that i haven't made the latest the official release. So I'm going to hold off until we resolve this discussion

@jaimergp
Copy link
Member Author

So, are we going to keep making micromamba and conda-standalone with the older glibc versions?

We can either do that, or add some bash code to find out about __glibc and __osx without conda in that PR. We can also add some error handling to the conda-standalone crash saying something like "We couldn't identify your system requirements. A possible explanation is that you may be using an older GLIBC version, but we require >=2.17".

Let me know which one is preferred.

@jaimergp
Copy link
Member Author

jaimergp commented Jul 25, 2024

add some bash code to find out about __glibc and __osx without conda in that PR

Ended up writing some code for this. Reviews welcome 🙏

@hmaarrfk
Copy link
Contributor

I take it we are waiting for your hard work to get merged:
conda-forge/constructor-feedstock#80

including this message for general visibility about the process!

@hmaarrfk hmaarrfk changed the title Enforcing system requirements Enforcing system requirements - Miniforge3 Blocker Aug 10, 2024
@hmaarrfk hmaarrfk pinned this issue Aug 10, 2024
@jaimergp
Copy link
Member Author

That's one blocker resolved, yes. Unfortunately there's another one in conda-standalone at conda/conda-standalone#90. We need that one to make a release including conda/conda-standalone#89.

It will be ready by EOD or Monday the latest.

@jaimergp
Copy link
Member Author

Sorry about the delay. conda-forge/conda-standalone-feedstock#79 is now merged so this should get unblocked briefly. We need to add the virtual_specs config to our config. Opening a PR now.

@hmaarrfk
Copy link
Contributor

I was hoping we could have "1 release" without any blackouts periods, so we can tell people that need to freeze to an older installer to use that.

is that still on the table?

@jaimergp
Copy link
Member Author

We will need to comment out a couple things in the input file, but yes, we have time. We can release brownout-equipped release right after.

@hmaarrfk
Copy link
Contributor

great! thanks.

In supporting people at my company i find that error messages need to have clear instructions with them.

You are encouraged to do X. But if you want, you can pin to Y and add to your technical debt.

is the kind of message I envision.

@marcoesters
Copy link

FYI, we just released a patch version for constructor that should move #626 forward once the package is built and uploaded.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
4 participants