Feat/info

[franciscocpg]

This feature enables printing some glide.yaml info as described in the usage:
glide info

NAME:
   glide info - Info prints some information about this project based on glide.yaml

USAGE:
   glide info [command options] [arguments...]

OPTIONS:
   --format, -f     Format of the information wanted. Variables:
                        %n - name
                        %d - description
                        %h - homepage
                        %l - license
                        %v - version

                        Examples:
                        Given the project with the following glide.yaml:
                        package: foo
                        version: 1.0
                        homepage: https://foo.io
                        license: MIT
                        description: Some foo description

                        Then:
                        glide info -f %n
                              prints 'foo'
                        glide info -f "Version: %v"
                              prints 'Version: 1.0'
                        glide info -f "%n - %v - %d - %h - %l"
                              prints 'foo - 1.0 - Some foo description - https://foo.io - MIT'

[mattfarina]

@franciscocpg thanks for the pull request. I like being able to pull more information.

Why the addition of the version property to the glide.yaml file? Shouldn't this information be pulled from the underlying VCS the code resides in? Setting aside Svn, there are ways to call into the VCS to get a version like 1.5.1 (a tag) or 1.5.1-11-gd93703f that says it's 11 commits past 1.5.1 and the commit id (short version). Wouldn't this be better than doing double duty to maintain versions in both tags and in the glide.yaml file?

[mattfarina]

What if no format is passed in?

[franciscocpg]

If no format is passed in then the help command is printed. Format is a mandatory option.

[franciscocpg]

Hi @mattfarina.
I agree with you that this is a best practice, but I think that it should not be mandatory. Some people prefer to control versions outside the VCS. One of the advantages of doing this is that your app version is not tied to VCS and you can change to any other VCS without any problems.
Besides that the version property is not mandatory in the glide.yaml. The idea is not to doing double duty to maintain versions in both tags and in the glide.yaml file, but to use one or another way.

[sdboyer]

Ahh...yeah, IMO, it's a hard no on having versions in the manifest. 😢 Because I can't direct link into spots in my article (ugh, medium), here's the quote:

For example, the above Cargo manifest has a ‘package.version’ field:

 [package]
 version = "0.2.6"

Think about it this a little. Yep: it’s nuts! Versions must refer to a single revision to be of use. But by writing it into the manifest, that version number just slides along with every commit made, thereby ending up applying to multiple revisions.
Cargo addresses this by imposing constraints in the registry itself: publishing a version to crates.io is absolutely permanent, so it doesn’t matter what other commits that version might apply to. From crates’ perspective, only the first revision it sees is associated with the version.

To my mind, it's not a question of good or poor practice; allowing versions in the code itself introduces a fundamental ambiguity in the way we understand time and version. The in-code and meta-code versions are non-equivalent, and having them trying to coexist in the same packaging ecosystem system introduces undecidable problems - certainly in practice, possibly even in theory - for any tool.

At minimum, we have to have rules like "use tags, but if they're not there then use a version in the manifest," which leads to confusing UX for users, in addition to the near-guarantee of disagreement between the two systems.

IF Go had a central package manager like crates, then this could be feasible - we could use it to enforce the same way they do. But we don't. Go was designed around a VCS-driven ecosystem from the start, and I don't know of a way to keep the problem sane if we undermine that.

I'm happy to go into more detail if the depth of the problem this would create isn't clear.

One of the advantages of doing this is that your app version is not tied to VCS and you can change to any other VCS without any problems.

There are tools that facilitate cross-VCS migration, certainly including tags. But, two things:

• Changing VCS often entails changing import paths anyway (due to hosting changes), so the import path changes...so, semantically, changes in versions aren't that disruptive to downstream users, because you're already a wholly different project at a different import path.
• The process of changing VCS itself is typically difficult enough that difficulties with your package manager are likely to be a negligible afterthought. (This, coming from a guy who architected the migration of >10,000 projects from CVS to git for the Drupal community).

It seems to me that the benefits on this front are pretty small, and they don't outweigh the costs.

Besides that the version property is not mandatory in the glide.yaml. The idea is not to doing double duty to maintain versions in both tags and in the glide.yaml file, but to use one or another way.

Mandatory-ness isn't the problem. By having the data there at all, we have to decide how to reconcile it with all the other version data floating around out there.

[sdboyer]

to be clear, i'm not raining on the idea as a whole - just the addition of a version field

[franciscocpg]

Hi @sdboyer.
Thank you for the explanation.
I read your article and your considerations and removed the version field.
I have merged with version field to my master branch in my fork because I am still tending to think that code version (every commit and its hashs, for example), build version and release version can be different things.
But I can change my mind in the future, 😄.
Maybe for golang and the VCS-driven ecosystem model really doesn't make sense. I don't know, still confused, 😕.

Anyway, I hope you guys can approve my PR now, 😀.

[mattfarina]

@franciscocpg We may not be explaining the version handling well. Being that version handling and VCS is common in software we may be jumping over some details.

These may be details you already know but I don't want to assume anything.

• A version should only point to a single commit. So, version 0.10.2 of Glide is really 2d0eb38. This should never change.
• A version to a single point in time is needed for reproducible builds. Only in that single commit will you be sure to have the same behavior.
• Versions provide meaning that commit ids don't. That's where their use comes in. SemVer provides for semantic format. A stable release with a version is giving the intent the author(s) believe the release is stable. Otherwise it may not be.
• The common way to handle releases in software is a tag in a version control system. This assumes you are using version control (and all software should be under version control... I'm happy to explain why for anyone who doesn't know).

If the version were listed in the glide.yaml file and carried between versions how could you tell which version was the release?

For example, in git I can run git describe --tags. If I were on the 0.10.2 release it would return that. If I were after it I would get something else like 0.10.2-3-g77c0ee9. This is 3 commits after the release and the short hash is on the end. This is between releases and unique.

Version ranges are entirely different. They are great for solving for the right versions to use and Glide supports those. It's just not good here.

Does that help?

[franciscocpg]

@mattfarina, yes.

[mattfarina]

@franciscocpg thanks for the contribution.

I did update the help text but otherwise this works. We can, in the future, add version handling that talks with the VCS.