You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Conda-devenv has become the very basis of our projects as Grade does. As our intentional common build mechanism, we currently are encountering the case that not each of our agent will be well prepared with dev-env, some might even be missing the Anaconda. As the policy goes the only sure-to-be-there thing is a JRE with not controllable version.
I know I can be achieving that by pulling our Anaconda installer from our internal repo and inject site wise configurations and then install dev-env accordingly. And that is only the first step, then everything just gets started handled by dev-env.
Is it possible to have a minimal packed distributable archive for dev-env? It is expected to do nothing other than providing working dev-env executables.
Say Gradle itself is definitely huge and with complicates setup procedures. So they created grade wrapper which is nice and neat and tiny and enough for setting Gradle up. Perhaps we could achieve the same? Was there any thought once brain-stormed on this? Grade wrapper works with a tiny Jar and one bat script and one shell script and one configuration file. That's all. (But of course it requires jre to be existing, we could also be expecting that there is an living Anaconda/Python outside) . What I want is simply that we don't have to install dev-env properly before using it. It has become to like a cornerstone now for us that we don't want too many preconditions before making use of it.
The text was updated successfully, but these errors were encountered:
Conda-devenv has become the very basis of our projects as Grade does.
Cool, but sorry, what's "Grade"? Not familiar.
What I want is simply that we don't have to install dev-env properly before using it. It has become to like a cornerstone now for us that we don't want too many preconditions before making use of it.
conda-devenv is an extension to conda, not a standalone-application.
Note however that you don't need a full blown Anaconda installation, you can install miniconda and then install conda-devenv on the root environment. That's what we do at ESSS.
If you don't have permissions to install things properly on the target machine, I assume that zipping a local miniconda installation with conda-devenv already installed, and then extracting that zip file in the target machine might work, although we have never tried this ourselves.
Conda-devenv has become the very basis of our projects as Grade does. As our intentional common build mechanism, we currently are encountering the case that not each of our agent will be well prepared with dev-env, some might even be missing the Anaconda. As the policy goes the only sure-to-be-there thing is a JRE with not controllable version.
I know I can be achieving that by pulling our Anaconda installer from our internal repo and inject site wise configurations and then install dev-env accordingly. And that is only the first step, then everything just gets started handled by dev-env.
Is it possible to have a minimal packed distributable archive for dev-env? It is expected to do nothing other than providing working dev-env executables.
Say Gradle itself is definitely huge and with complicates setup procedures. So they created grade wrapper which is nice and neat and tiny and enough for setting Gradle up. Perhaps we could achieve the same? Was there any thought once brain-stormed on this? Grade wrapper works with a tiny Jar and one bat script and one shell script and one configuration file. That's all. (But of course it requires jre to be existing, we could also be expecting that there is an living Anaconda/Python outside) . What I want is simply that we don't have to install dev-env properly before using it. It has become to like a cornerstone now for us that we don't want too many preconditions before making use of it.
The text was updated successfully, but these errors were encountered: