Discuss renaming lock.json and manifest.json

[bradleyfalzon]

Raising an issue to ensure this is tracked and closed.

As discussed in the Go Package Management mailing list (https://groups.google.com/forum/#!topic/go-package-management/et1qFUjrkP4), there were some thoughts about names and locations of the lock and manifest files. Broadly speaking:

• There was some concern with storing the files in the root repository directory, others have suggested other folders, such as within /vendor/. Storing in /vendor/ could cause issues with a VCS if that directory is also being ignored.
• I raised that if we are to store the files in generic directories, this could cause collisions with other package managers in use for other languages in the same project.

Personally, I don't mind which directory they are stored in, however, if they are generic directory names, to reduce the chance of name collisions, we should reconsider the names manifest.json and lock.json, such as gomanifest.json and golock.json?

I'm on the fence on this issue, just thought it should be raised formally.

[sdboyer]

Yeah, thanks for writing this up.

I raised that if we are to store the files in generic directories, this could cause collisions with other package managers in use for other languages in the same project.

This does concern me. I've always been annoyed that e.g. package.json's name doesn't have any obvious linkage to npm. Potential naming collisions with other systems are an issue as well.

Of course, WHAT we name it is...the mother of all bikesheds. It kinda brings us back to #25 (which we ultimately rolled back), except that it's even more permanent, because even if/when this tool hopefully becomes official, gets integrated into the toolchain and the name goes away...the manifest and lock files will need to retain the same names.

There was some concern with storing the files in the root repository directory, others have suggested other folders, such as within /vendor/. Storing in /vendor/ could cause issues with a VCS if that directory is also being ignored.

This one's a hard no. Please, let's just drop it right now. Manifest/lock files go in the root. I don't want to even give reasons, lest it invite even more bikeshedding than we're already risking with names.

[pbennett]

I think at a minimum, the prefix of the two files should be the same.
godep[-]lock.json, godep[-]manifest.json. That sort of thing.
manifest.json and lock.json are IMO far too generic and there's nothing to indicate they have anything to do with each other.

[zolotov]

+1 for less generic names for these files to avoid false positive results while determining whether the project is backed by dep tool. gomanifest/golock looks good to me.

[nathany]

This one's a hard no. Please, let's just drop it right now. Manifest/lock files go in the root. I don't want to even give reasons, lest it invite even more bikeshedding than we're already risking with names.

The other Go tools put these files in vendor/. I don't really care where they go, but the discrepancy is one of the first things I noticed. Unless there is a reason in a FAQ somewhere, I suspect the question will be raised multiple times. Guess we can wait and see.

[sdboyer]

@nathany that's fine - we can write up the reasons elsewhere. I just don't want to derail this issue.

[nathany]

Regarding the naming...

How important is it to have .json as the extension? Bundler (Ruby) and Hex (Elixir) use .lock as the extension for the lock file.

If the tool is going to be dep going forward (e.g. go dep ...), then how about dep.json? And perhaps dep.lock or dep.lock.json?

[nathany]

Manifest may not be the right name.

manifest |ˈmanəˌfest|
a document giving comprehensive details of a ship and its cargo and other contents, passengers, and crew for the use of customs officers.

Unlike other tools, dep treats imports in the code as the source of truth.

The file we've called manifest thus far really could (and probably should) be a human-editable file to wrangle with the solver, specifying constraints when the defaults aren't enough. It doesn't need to contain the full details, certainly not the transitive list of dependencies (that is the lock file's job).

[bradleyfalzon]

How important is it to have .json as the extension? Bundler (Ruby) and Hex (Elixir) use .lock as the extension for the lock file.

Important if:

manifest thus far really could (and probably should) be a human-editable file to wrangle with the solver

Then it could be easy to double-click a file to open an editor and the editor knows what the format is.

[joeshaw]

On the topic of renaming the manifest and lock files (which I support), here are uses of files named manifest.json and lock.json among existing Go files on GitHub:

https://github.com/search?utf8=%E2%9C%93&q=%22manifest.json%22&type=Code&ref=searchresults&l=go

https://github.com/search?utf8=%E2%9C%93&q=%22lock.json%22&type=Code&ref=searchresults&l=go

lock.json appears to not be an issue, but manifest.json likely would.

[nathany]

@bradleyfalzon Yes, the editor knowing the format could be of some benefit, especially if the manifest is human-editable.

A counter-argument is that if the files aren't intended for human consumption, the names and location (#207) could reflect that. E.g. deps.lock is a file that I'm not expected to look at or modify (it's an implementation detail).