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

x/vgo: go.mod should have a different name #23972

Closed
davecheney opened this issue Feb 21, 2018 · 15 comments

Comments

@davecheney
Copy link
Contributor

commented Feb 21, 2018

Hello,

I don't think go.mod should be called go.mod, or more specifically anything.mod.

My reason is.mod is a file extension. Maybe this was not the intention, but it's my interpretation. The .mod extension implies that there can be a set of .mod files in a module, just as there can be a set of .go files.

go.mod should be renamed to something singular, and i'm going to suggest module as the replacement.

@cznic

This comment has been minimized.

Copy link
Contributor

commented Feb 21, 2018

The .mod extension implies that there can be a set of .mod files in a module, just as there can be a set of .go files.

My interpretation is that a file extension implies only that there could be more than one file in a directory having the same name modulo the extension as long as the extensions differ.

@davecheney

This comment has been minimized.

Copy link
Contributor Author

commented Feb 21, 2018

@drewblas

This comment has been minimized.

Copy link

commented Feb 21, 2018

I agree the name should be changed. .mod implies a given syntax and file format. Editors now have to add support separately for knowing that a go.mod file is a special file with special meaning

Many other projects have suffered similarly with arbitrary project-root files. e.g. Ruby/Bundler recently switched from Gemfile to gems.rb.

Since the file is very close to go syntax, it should be understood "I'm looking at a go file", not a special bespoke file (though discussion on the format inside the file is ongoing in #23966).

It may be difficult to introduce a default that could conflict with existing filenames in go projects. Maybe a scan of all public go repos would reveal how many collisions there might be with a name like deps.go or dependencies.go and see if we can "ask nicely" for a rename?

@4ad

This comment has been minimized.

Copy link
Member

commented Feb 23, 2018

Why should there be only one *.mod file? I can imagine having a machine-generated go.mod file with the possibility of a programmer-written *.mod file next to it. Say, for example, for debugging you could redirect a dependency to a local version with local changes.

You could do it in go.mod itself, but then it gets harder when version control is involved. You probably don't want to commit those particular changes to the go.mod file. This is easy to avoid in git, but difficult (impossible?) in other systems. And even with git, you might want to update go.mod (automatically), while still working with your private debug package.

Probably go release should verify that all the *.mod files are version controlled before creating a package.

I don't know if this idea necessarily has merit, but I don't see why we should make it impossible by removing the file extension.

@gavincabbage

This comment has been minimized.

Copy link

commented Feb 28, 2018

That @davecheney and @4ad interpret the the situation so differently indicates a need for some clarification on the intent of the module file. I wonder what @rsc was thinking when he was writing the proposal. The community should make a decision sooner rather than later because it definitely steers the conversation on naming the file.

I also think @drewblas' point is worth consideration, depending on how close to Go code the mod file syntax ends up. Reminds me of Python's setup.py, though a module.go couldn't work as mentioned.

@sprstnd

This comment has been minimized.

Copy link

commented Feb 28, 2018

I think the point being made by dave is that the new file extension should try to be universally unique as possible instead of just unique within go. This is a wise choice considering the elimination of path.

@davecheney

This comment has been minimized.

Copy link
Contributor Author

commented Feb 28, 2018

I think the point being made by dave is that the new file extension should try to be universally unique as possible instead of just unique within go.

For clarification, my request is that the module file not have an extension, so that there can be only one module file per directory.

@sprstnd

This comment has been minimized.

Copy link

commented Feb 28, 2018

okay, I believe the file should have an extension but that file extension should try to be universally unique at possible. I believe file extensions help things run smoothly in windows.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Apr 2, 2018

@davecheney's argument against go.mod is that using an extension implies that varying the base name is meaningful. A few thoughts.

First, as @cznic points out, it could equally well imply that varying the extension is meaningful (go.mod, go.modverify, go.txt, and so on).

Second, I can easily see adding an option to the go command -M file to say "build with this other file instead of the current go.mod". I can also see that other file being named <something else>.mod. I would not read *.mod by default like @4ad suggests, but I don't see why being able to write *.mod to identify these different files in one glob is a bad thing. And editors can look for *.mod and so on.

Third, I think the file needs some extension. I'm not a fan of extension-less files, especially those suffixed with "file": makefile, dockerfile, etc. The custom extension makes collisions far less likely.


The discussion also raised using Go syntax. It's not Go, nor will it become Go. It's meant to be evocative of Go but also obviously different, to avoid confusion. The necessary semantics are different enough from Go that reusing Go itself is not a good fit. The current file format is arguably too close to Go, and I intend to make the quotes optional (and canonically omitted) to distance it a bit more.

It's important to me that resolving modules not involve running arbitrary code, as in setup.py or (I assume) gems.rb.


Going to keep go.mod for now.

@rsc rsc closed this Apr 2, 2018

@sprstnd

This comment has been minimized.

Copy link

commented Apr 8, 2018

This is unfortunate. Not everyone and not everything is done through a CLI. In windows it is not uncommon for a workflow to be done with point and clicks through gui interaction. The file extension should try to be universally unique as possible. Now there will be inevitable conflicts.

@adg

This comment has been minimized.

Copy link
Contributor

commented Jul 17, 2018

I'm disappointed that the name go.mod appears to have been decided upon, despite the fact that .mod files are already a thing (and yes, people still use them, myself included). go.module seems fine to me.

I am reopening this issue in the hope that this can be revisited.

@adg adg reopened this Jul 17, 2018

@cznic

This comment has been minimized.

Copy link
Contributor

commented Jul 17, 2018

FTR: Here's another thing associated traditionally with the .mod extension.

@jbrodriguez

This comment has been minimized.

Copy link

commented Jul 17, 2018

It should even be configurable, with a sane default (go.modrc ?)

@adg

This comment has been minimized.

Copy link
Contributor

commented Jul 17, 2018

@jbrodriguez I can't be configurable; it has to be the same everywhere.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Jul 20, 2018

I'm really sorry, @adg, but it's too late to reopen this.

I know about the Amiga mod file format and that it is still used, but file extensions just aren't globally unique (there are already 5 entries for MOD on the Wikipedia list). I apologize for any software that tries to turn go.mod files into music, although I'm curious to hear what that would sound like.

@rsc rsc closed this Jul 20, 2018

@golang golang locked and limited conversation to collaborators Jul 20, 2019

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
You can’t perform that action at this time.