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
Add script to generate conda envs #367
Conversation
@manopapad @marcinz do you think it is desirable to add another dimension for @marcinz also suggested
Or are there additional packages? It's not clear e.g. how |
Let's remove the following packages if the user doesn't want to use the conda compilers:
CC @m3vaz Update: let's have 2 separate requirements, for openmpi (packages: openmpi) and compilers (packages: c-compiler, cxx-compiler). I think |
@m3vaz should we try to protect developers from trying to use a more recent gcc than what the system nvcc will accept? I see the cudatoolkit package defines a minimum required libgcc-ng, but not a maximum. We could try to restrict the gcc version on our env files to a maximum, corresponding to the nvcc on the requested CTK version. This would assume the user will be asking for the same CTK as the system-wide installation supports. |
@manopapad changes pushed, FYI this results in ~130 combinations
|
|
That's a good suggestion, I'll mention it on the corresponding issue nv-legate/cunumeric#629, and we don't need to do anything about it here. |
@manopapad should we split these into subdirectories? Perhaps by cuda version or os/cuda version? |
I was thinking we can just distribute the script, and tell the user to generate a conda env by running it, with appropriate options for their system. |
@manopapad 👍 I thought the intention was to check in identical sets in legate and downstream projects, but just distributing the script works too. But in that case we could add command like args to the script let users specify which config they want, in case they only want one or a subset. |
That's what I was also thinking initially, but if we're dealing with 100s of envs then I'm thinking it's probably less effort for the user to just invoke a script than to riffle through all the available options. Plus we're sparing our git history from that many files.
Yes, can we switch to a mode where the script just produces one env file, based on command line choices for the various dimensions? |
* Perform consensus match more frequently for bigger free fields * Minor cleanup
ex:
|
@manopapad Those look good, note that when we bump minpy to 3.9 we can get rid of the custom action
|
cc @manopapad
This PR adds a script to generate a matrix of conda envs for
All of them are labeled "test" for their use, and reproduce the structure of the existing "test" env files.
This can certainly be made more sophisticated (e.g. handling openmpi, or splitting different envs for different use scenarios). Currently generates the following files:
A sample env looks like: