What does my workflow look like when I have to administer both sceptre-v2 and sceptre-v1 projects?

[akdor1154]

Sceptre v2 projects will be incompatible with Sceptre v1, and vice versa (confirm?)

Eventually, all my projects will be migrated to Sceptre 2. However, especially in a large organization, there's going to be a reasonable period of time where I need to interact with both sceptre-v1 and sceptre-v2 projects.

How do I do this? The bludgeon approach would be to pip3 install sceptre<2 before I do sceptre v1 work, and pip3 install sceptre>=2 before I do sceptre v2 work. Alternatively I could manually set up virtualenvs and switch between them (imo even uglier, virtualenvs are a tool for development not for end users). However, it would be great not to have the installation of these CLIs be mutually exclusive.

I'm well aware that in terms of technical limitations, this is really a pip and not a Sceptre problem, but I am interested in what the Sceptre team thinks the workflow of someone in this position should look like.

The max-dev-happiness solution might be to have sceptre-v2 able to manipulate sceptre-v1 projects (obviously not the other way around), but this would be a huge amount of work, and (hence not surprisingly) it doesn't look like this is on the roadmap?

[1oglop1]

imo virtualenvs are way to go. Plus whoever is using sceptre is not "end-user" and should be aware of working with python. Same applies for the ansible or saltstack. It may be not needed but it really helps.

[akdor1154]

Worth considering from the CI agent point of view as well - do I need to have a separate agent for sceptre1 vs sceptre2 projects? (currently my own practices are to deploy with the same agent as used for builds, this is a bit cheeky but perhaps common? this would mean I need to have agents nodejs-sceptre1, nodejs-sceptre2, java-sceptre1, java-sceptre2, etc) Or should the CI scripts for my projects need to be aware of how to set up virtualenvs?