Allow pinning projects to specific versions

[jmatth]

A major feature we use in FVM that is currently missing from Puro is the ability to commit a file to a repo that pins the projects environment to a specific version. This use case was mentioned in #35, but the current implementation doesn't fully address it. When testing Puro I observed that if an environment was specified in .puro.json that did not exist, then Puro would change the contents of .puro.json to match the current global default:

$ puro ls
[i] Environments:
    ~ stable (stable / 3.16.0 / db7ef5bf9f)
      beta   (not installed)
      master (not installed)
    
    Use `puro create <name>` to create an environment, or `puro use <name>` to switch
$ cat .puro.json
{
  "env": "3.13.9"
}
$ puro use
[✓] Switched to environment `stable`
$ cat .puro.json
{
  "env": "stable"
}

This doesn't really help with the use case of pinning a version for a project, where:

• New contributors need an easy way to set up their environment w/ the correct version
• Existing contributors should have their environment easily switch versions as they navigate the repo history
• CI/CD builds always start with an empty environment and need to initialize with the pinned version

FVM handles this by automatically installing the version specified in its config file if it is missing as part of fvm use. I think it would be great if Puro offered the same functionality. Failing that, it should at least error out with a message to install the missing environment rather than quietly changing it to whatever the global default happens to be.

[pingbird]

That is definitely something I overlooked when implementing the logic for puro use, thanks!

It should automatically install the desired flutter version when running the puro flutter command, but ideally it also keeps your IDE config in sync with what's specified in .puro.json

[neiljaywarner]

@pingbird what would be really cool is if it could just detect from pubspec.yaml if pubspec.yaml has a flutter: 3.19.6 or whatever instead of a range. i have always found it sad that the max range is not respected anyway.

[neiljaywarner]

This is actually the biggest problem I'm looking to solve with a version manager.

[passsy]

@pingbird What's the status here. Would you like to have external contriutions for this?

[dsyrstad]

@pingbird We've been a long time puro user. We have a monorepo that has multiple subprojects, each with it's own pubspec.yaml. We currently have to run puro use ... on each subproject. It's up to the developer to know which version to manually update to when they clone the repo. We also currently have multiple branches each using different flutter/dart versions and it's a pain to switch between branches right now. We have a script that you have to run which calls puro use on each subproject when you change branches. Again, this requires you to remember to run the script when you change branches, and remember which version is needed. If you forget, it can wreak havoc on your build, possibly messing up pubspec.lock.

I'd like to suggest a solution for this:

1. .puro.json would stay the same as it is today and is not committed (it's in .gitignore). It would still include the env attribute. This allows for backwards compatibility.
2. Introduce a new file .puro_env.json that just contains the env attribute from .puro.json. This file can be committed and is not ignored by default. If .puro_env.json exists, its env takes precedence.
3. puro use ... would update both files.
4. The puro command (which is called by the wrapped flutter and dart commands), would look at .puro_env.json first for env, if it exists.

fvm allows you to commit the version you've chosen, but we really dislike that the SDK artifacts are part of your repo - even though they're ignored. You have to exclude them from IDE searches, and you have multiple copies of the same SDK.

What are you're thoughts on this?