Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

version manager for apm packages #583

Open
kernelwhisperer opened this issue Jul 5, 2019 · 2 comments
Open

version manager for apm packages #583

kernelwhisperer opened this issue Jul 5, 2019 · 2 comments
Labels
💬 needs discussion A feature not yet agreed on that needs more discussion

Comments

@kernelwhisperer
Copy link
Contributor

kernelwhisperer commented Jul 5, 2019

TL;DR

nvm, but for @aragon/cli, as well as other tools.

This will make pinning to a certain version as quick as few seconds and as easy as one command.

🚀 Feature

There is the use case where an app might be using a different version of the GUI client.

(currently this is hard coded in the CLI, but I think we need to move it to a configuration file, along with the gasPrice option and the others)

And there is also the use case where an app only works with a specific version of the CLI.

(currently people can install the CLI as a project depedency and pin it to a certain version)

Proposal

I wonder if it makes sense to centralize these versions under ~/.aragon, for example:

~/.aragon/cli/v5.9.3
~/.aragon/cli/v5.8.0
~/.aragon/cli/v5.6.2
~/.aragon/gui/v0.8
~/.aragon/gui/v0.7

And declare in the arapp.json/package.json or some other project-specific configuration file, which version it should use, e.g.: >= 5, <= 6.

This logic might also improve how the aragon-desktop handles GUI upgrades and downgrades. 🤔

The other solution

The alternative would be include these projects (gui, cli, etc.) as project dependencies... 🤔

  "@aragon/cli": "5.9.3",
  "@aragon/gui": "0.8.0"

Pros:

  • dependencies are more contained? (I'm not sure though, and if this becomes a problem we could to some integrity checking ourselves 🤷‍♂️ )
  • no global space pollution (I think people can still achieve this with docker though)

Cons:

  • slower (although I think npm will not download these packages over and over again, it still needs to copy the files from the local npm cache, and writing so many files to disk is still slow...)

I think the first solution makes more sense because these projects are not libraries like aragon.js or aragon-ui. They have more in common with tools like git, node, npm, which you have installed globally and you expect them to just work.

Possible interface

avm set-default @aragon/cli v5.9.3
avm set-default @aragon/gui v0.8

Now if I do aragon --version it will print v5.9.3, but if my cwd is a project and its package.json says:

  "aragon" : {
     "cliVersion": "v5.6.0",
     "guiVersion": "*"
   }

Doing aragon --version should actually print v5.6.0.

@kernelwhisperer kernelwhisperer added the 💬 needs discussion A feature not yet agreed on that needs more discussion label Jul 5, 2019
@kernelwhisperer
Copy link
Contributor Author

Now if I do aragon --version it will print v5.9.3, but if my cwd is a project and its package.json says:

  "aragon" : {
     "cliVersion": "v5.6.0",
     "guiVersion": "*"
   }

Doing aragon --version should actually print v5.6.0.

On second thought, this might be too much magic and could cause problems.
It would be better if the CLI would throw an error instead.

So if package.json says:

  "engines": {
     "aragonCLI": "> 5.0.0"
  }

And you are using v6.0.0, it should error saying: "This project is only compatible with v5 of the aragonCLI, please use avm set-default @aragon/cli v5.9.3 to switch"

This would also allow us to start using the CLI globally and remove it from repos before we have the "apm version manager" feature.

@kernelwhisperer
Copy link
Contributor Author

solc-select has nice UX too, using an environment variable to switch between versions: https://github.com/crytic/solc-select#usage

@0xGabi 0xGabi added the next label Oct 21, 2019
@theethernaut theethernaut removed the next label Jan 2, 2020
@stale stale bot added the abandoned label Jul 1, 2020
@macor161 macor161 removed the abandoned label Jul 1, 2020
@aragon aragon deleted a comment from stale bot Jul 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
💬 needs discussion A feature not yet agreed on that needs more discussion
Projects
None yet
Development

No branches or pull requests

4 participants