Anacond3.4.1.1 silent install and updates

[Andrew]

Hi,

My University want to have Anaconda installed on a suite of machines.  I'm able to do this easily enough using SCCM and a few command line switches in a script.  The issue is that our main test user is saying that the package needs updating before it will work as anticipated (I have used Anaconda3-4.1.1-Windows-x86_64.exe which at the time or writing is the latest version).  I'm loathed to ask him to manually run 'conda update ipython' on every machine...is there a way to script these updates during installation?

Thanks

[Ian Stokes Rees]

Hi Andrew,

On 9/22/16 9:58 AM, Andrew wrote:

My University want to have Anaconda installed on a suite of machines.  I'm able to do this easily enough using SCCM and a few command line switches in a script.  The issue is that our main test user is saying that the package needs updating before it will work as anticipated (I have used Anaconda3-4.1.1-Windows-x86_64.exe which at the time or writing is the latest version).  I'm loathed to ask him to manually run 'conda update ipython' on every machine...is there a way to script these updates during installation?

TL;DR: Not really possible, but Conda environments should let them self-serve to have the latest versions, and in any case Anaconda 4.2 will be released in the next few weeks (with the latest versions of everything).

I'd suggest another conversation with your primary user and to understand what they expect to do with Anaconda.  The 200 packages in there are being updated daily to new versions.  Does that user expect the system-wide installation of Anaconda to change every day?  Probably that would be a bad thing (although some people, myself included, have made the mistake of thinking it would be a good thing).  I would encourage that user to understand that there are quarterly "packaged" releases of Anaconda, and that the most stable thing for your university would be to update once or at most twice a year for the system-wide versions of Anaconda.  Truly people won't thank you when the versions of Python libraries or R tools that they are using are changing under their feet.

And then discuss if it is viable for them to use Conda environments.  If they want a more recent version they should be able to do:

```bash
conda create -n mycustomenv anaconda python=X.Y # (they can pick their favorite Python version)
source activate mycustomenv
conda update ipython foo=a.b bar=c.d etc etc
```

And then they'll have their own custom Conda environment with just exactly the versions (or just the latest versions) of the packages they want.

Anyway, I understand that their may be obstacles to allowing end users to create Conda environments.  But really that would be the best solution if you can find a way to do that.

And finally (which may solve your **immediate** issue), there will be a new release of Anaconda very soon (days to weeks).

We'd love to know more about your use of Anaconda -- feel free to drop me a private email any time.  Understanding how to make Anaconda work well for universities is important to us.  I should note that there are many known limitations of installing Anaconda on a central server and then accessing it in a multi-user fashion (I'm not sure if that is what you're doing).  Anaconda Enterprise, our commercial product, is designed to address some of those challenges to improve management for multi-user and multi-host Anaconda deployments.

Cheers,

Ian

[Andrew]

Hi Ian,

Thank you very much for your timely and detailed reply - most useful.

To be honest, the deployment wasn't overly difficult in comparison to some of the products our users ask for.  If I was being nitpicky, I'd say that an MSI would be more useful for enterprise deployment, but it isn't a anything we can't script.

In terms of the environments etc that you speak of, I am not familiar with the software at all to really comment too much.  I'm not 100% sure the user is totally sure what their issue is precisely, so I guess figuring out what their issue is would be a good start.  We keep quite a tight control of what our users can and can't do on our machines and so multiple environments for different users may complicate matters somewhat.

It sounds like the users managing their own updates would be easiest if they are as frequent as you say - we don't have the time to work on packages too many times a year as it is.

Thanks again

Andrew