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.

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?

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.

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.

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.

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.

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.

@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.

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.

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.

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

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

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

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.