Migrate to denolib/dvm

[axetroy]

I found the community, the only version management available is justjavac/dvm, But written in nodejs.

it have runtime dependencies, I am not happy for this.

I want to migrate it to denolib/dvm and maintained by the community

How do you think?

@kevinkassimo @justjavac @zhmushan @kt3k

[zhmushan]

I use scoop on Windows to manage the deno version, I don't know if dvm will be more useful on other systems. If other systems do require version management tools, I think migrating dvm to denolib is appropriate.

[kt3k]

On mac, I use asdf, a generic version manager for languages, which has deno-plugin and that works for me. I'm not sure it's worth the effort.

[axetroy]

@zhmushan scoop is a package manager for Windows. not version manager.

It's not like nvm, you can easily switch versions

For example, there is a script that references the API of v0.25.0, but the API was deprecated in v1.0.0

At this time, a simple method is needed to switch versions

At the moment, I think it's worth it

[axetroy]

@kt3k Same reason as above

[kt3k]

I think asdf is actually version manager for general language. You can switch between versions of deno, just like what nvm does for node.

$ asdf global deno 0.24.0
$ deno --version
deno: 0.24.0
v8: 8.0.192
typescript: 3.7.2
$ asdf global deno 0.26.0
$ deno --version
deno 0.26.0

If scoop isn't a version manager, I think it's worth doing for windows.

[zhmushan]

scoop:

PS> scoop reset deno@0.25.0
Resetting deno (0.25.0).
Linking ~\scoop\apps\deno\current => ~\scoop\apps\deno\0.25.0
Creating shim for 'deno'.
C:\Users\zhbnh> deno -V
deno 0.25.0

[axetroy]

yeah. I got this. at least each platform has its own solution. Thanks all ❤️

[kevinkassimo]

Worth noting I'm not against moving different implementations to denolib.

Besides this dvm implementation, I have also seen this implementation in OCaml.

Maybe a good idea is to see how different implementations grow with popularity in time to decide which one to adopt to denolib though (or even to denoland if Ryan thinks an official version manager can be a good idea)

[smorimoto]

Oh, I just noticed what is mentioned here. Yes, it's good to see the movement of the community. I'm using Jane Street's Core, so I can't build for Windows at this time. It would be nice to implement without Core, but I'm not going to do that.

[smorimoto]

and I recently added the latest and gc commands at the request of my friend.

[smorimoto]

The reason I don't support Windows is because I don't have enough bandwidth and I'm writing this for my friends. Probably the most common and easiest to use right now is asdf. (To be fair, I am the maintainer of the asdf-deno.)

[zhmushan]

@axetroy I disagree with my previous point.

I recently started using ubuntu, and after trying many tools, I found dvm is the easiest way to manage multiple versions of deno. If you don't have much energy to maintain this tool, I think it is a good idea to migrate to denolib (At least I am very interested in becoming a maintainer.

[axetroy]

@zhmushan I have no opinion on this

But it seems that denoland prefers to use rust. ref: https://github.com/denoland/deno/issues/5214

Maybe soon, the official deno release will have its build-in version management

[zhmushan]

@axetroy Maybe we can use rust rewrite based on your code, and temporarily release it under denolib to wait for official adoption

[justjavac]

I use asdf now

[smorimoto]

The latest asdf-deno plugin set DENO_INSTALL_ROOT and DENO_DIR by default. (Of course you can override it by setting it yourself.)