Correct way to use deploy and/or active project

State Tool
,
2

Hi @IanBadcoe ! Thanks for the very detailed explanation – you’re actually totally right in that your explanation:

The situation is that I will configure this on my machine but, when others join the project, they will need to get the same configuration as I have. I was imagining we could do that by telling them to deploy the same project I was

Is totally correct – there’s just a few details I think that are dependent on your exact configuration. So in general, to achieve the above, what you would do is:

  • Create a project – normally as you found out, you start from the Web UI. You can then add the packages you want either via the web UI or via state install. The reason you want to create a project is that it creates a shared source of truth for what your configuration is amongst your team members. It’s also revisioned so that it’s always reproducible.

  • Anyone who wants to use that configuration simply activates the project, by typing state activate myOrg/myProject – this will install everything you set up in your project on their machine. Now, here’s where I think there might be confusion – unlike “installing” Perl on your machine via an installer, what activate does, is it sets up a virtual environment–like a sandbox that is a totally self-contained Perl installation. This means that if you want to switch projects to another Perl with a different set of packages, you can easily do so just by “activating” a new project. It’s also worth nothing that the project is only “activated” within the shell that you’re currently running, so if you have other processes that need to access Perl, that’s where deploy comes in.

  • If you need a sort of classic “installation” of Perl that can be globally accessed on your machine by other processes, etc. then you can use state deploy and this will basically “install” Perl on your machine. You might need to setup some PATH variables to point it at the installation like PERL5LIB, and add the location where you deployed it to your PATH so that it can find perl.exe, etc. But once deployed you do NOT need to activate.

  • The other thing you mention is state push – so, if you’re familiar with git – this is the same concept. When you run state install – any changes you’re making are ONLY on your local machine. If you want to “push” them to the platform (at which point they’re shared with all your team members), then you run state push and it will push those to the platform.

Hope that helps clarify some of the concepts used on the platform – happy to explain more if there are other questions.

1 Like