Add "version" command to pkg

The current behaviour is the following:
image

I feel that “version” is a more natural command, and that it should be added to return the same thing as “status”. It should save a lot of people trying “version” first, and then googling the correct command “status”.

Is there a good reason not to do this?

1 Like

This seems like a reasonable idea.

Multiple commands for the same thing is usually not very good.

Are there a lot of people trying version? Is there another package manager that uses version or why would you assume that to be available in Pkg?

7 Likes

version seems like a pretty good guess for how to get the version of a package. Julia’s package api generally uses the most obvious name for the operation. status is probably right for the status of all packages, but to get a version of a specific package, version seems reasonable.

2 Likes

Maybe instead of “Could not determine command” we could print “unknown command $cmd.\nAvailable commands: add, dev, up, st, …”

4 Likes

I think it would be better to hint to the help command, because otherwise we would have to decide which commands to include and this could become cluttered very quickly.

5 Likes

Couldn’t version just return 1.7.1?

3 Likes

Even if not as a command, then as an option the version (--version, -v) is quite common elsewhere, isn’t it? I can understand why it is somebody’s first guess.

And Matlab uses version and ver as commands.

>> version

ans =

    '9.11.0.1769968 (R2021b)'

>> ver Simulink
-----------------------------------------------------------------------------------------------------
MATLAB Version: 9.11.0.1769968 (R2021b)
MATLAB License Number: ...
Operating System: Linux 5.11.0-38-generic #42-Ubuntu SMP Fri Sep 24 14:03:54 UTC 2021 x86_64
Java Version: Java 1.8.0_202-b08 with Oracle Corporation Java HotSpot(TM) 64-Bit Server VM mixed mode
-----------------------------------------------------------------------------------------------------
Simulink                                              Version 10.4        (R2021b)

This is not to say that Julia should follow Matlab, I am far from that attitude and I am happy that Julia goes its own way, it is just that you were asking.

2 Likes

Good suggestion https://github.com/JuliaLang/Pkg.jl/pull/2811

1 Like

This is a good point. But in some cases, aliases are useful. I point to Vector{Float64} (alias for Array{Float64, 1}) as an example where I think we all agree that this rule can be broken. Because I do not see the harm in having an alias here, I am still in support of it.

I don’t have data on how many people do this. But I naivly did this myself, and I have spent a fair amount of time reading documentation etc - more that I expect the casual user to have done. So my thinking is that if I messed it up, I am certain that I am not first nor last.

That would be great! I actually think that the following would make a lot of sense:
(@v1.6) pkg> version returns the current Julia version.
(@v1.6) pkg> version SomePackage returns the version of SomePackage.
(@v1.6) pkg> versions returns same thing as status, but with the julia version as the first entry, making it a complete list of all version of the current enviroment.

I think that these commands are so natural, that even if one would want to use the commands for something else, one should not do it, as I think my suggestions would be the expected output for most users.

5 Likes

I see the usual harm of adding uncertainty, and making Pkg easier to get something working by chance (by guess), but harder to master. For example if I found by chance that version works, then later see someone mentioning status, I won’t be sure if it’s the same thing. Making things fuzzy like that is a bad idea I think. On the contrary if I know there aren’t aliases left and right, if I learned status and see a mention of version, I know there’s a new interesting command for me to learn.

By the way Vector as an alias for a certain kind of Array makes sense: it corresponds to something more specific than Array and makes code more readable. I’m happy we don’t have e.g. Table as alias for Array because that would be redundant :slight_smile:

4 Likes

Alright, I have found your comment rather persuasive. How about adding a hint for what the user might mean? Similar to the line starting with search: returned in this example.

help?> version
search: versioninfo VersionNumber VERSION reverseind

Couldn't find version
Perhaps you meant versioninfo
  No documentation found.

  Binding version does not exist.

And making it so that st and status show up when the input is version.

1 Like

https://github.com/JuliaLang/Pkg.jl/pull/2811 is enough to “fix” this, in my opinion.

6 Likes

I agree that it is enough. But would it not be even better for a new user to give some educated guesses, as is currently implemented in help mode? If yes, then why not do it?

The hint is just based on textual similarity so it wouldn’t link version and status anyway.

I was thinking that one could add a sentence about version in the docstring for status. But it could be true that that is more trouble than it is worth, and that all is swell now with PR#2811 merged.