mvs is a flexible tool and library based on Go mods.

Use and create module systems with Minimum Version Selection semantics and manage dependencies go mod style. Mix any set of language, code bases, git repositories, package managers, and subdirectories. Manage polyglot and monorepo codebase dependencies with 100% reproducible builds from a single tool.

• Based on go mods MVS system, aiming for 100% reproducible builds.
• Recursive dependencies, version resolution, and code instrospection.
• Custom module systems with custom file names and vendor directories.
• Control configuration for naming, vendoring, and other behaviors.
• Polyglot support for multiple module systems and multiple languages within one tool.
• Works with any git system and supports the main features from go mods.
• Convert other vendor and module systems to MVS or just manage their files with MVS.

Language support:

• golang - delegates to the go tool for the commands mirrored here
• cuelang - builtin in default using the custom module feature
• hofmods - extends Cue with advanced code generation capabilities
• custom - Create your own locally or globally with .mvsconfig files

Upcoming languages: Python and JavaScript so they can have an MVS system and the benefits, and mvs can start supporting and fetching from package registries. These language implementations will have flexibility to manage with mvs and the common toolchain to varying degrees. Pull requests for improved language support are welcome.

The main difference from go mods is that mvs, generally, is not introspecting your code to determine dependencies. It relies on user management of the <lang>.mods file. Since golang is exec'd out to, introspection is supported, and as more languages improve, we look to similarly improve this situation in mvs. A midstep to full custom implementation will be a introspection custom module with some basic support using file globs and regex lists.

Note, we also default to the plural <lang>.mods/sums files and <lang.mod>/ vendor directory. This is 1) because cuelang reads from cue.mod directory, and 2) because it is less likely to collide with existing directories. You can also configure more behavior per language and module than go mods. The go mods is shelled out to as a convience, and often languages impose restrictions.

# Print known languages in the current directory
mvs info

# Initialize this folder as a module
mvs init <lang> <module-path>

# Add your requirements
vim <lang>.mods  # go.mod like file

# Pull in dependencies, no args discovers by *.mods and runs all
mvs vendor [langs...]

# See all of the commands
mvs help

The module file holds the requirements for project. It has the same format as a go.mod file.

# These are like golang import paths
#   i.e. github.com/hofstadter-io/mvs
module <module-path> 

# Information about the module type / version
#  some systems that take this into account
# go = 1.14
<lang> = <version>

# Required dependencies section
require (
  # <module-path> <module-semver>
  github.com/hof-lang/cuemod--cli-golang v0.0.0      # This is latest on HEAD
  github.com/hof-lang/cuemod--cli-golang v0.1.5      # This is a tag v0.1.5 (can omit 'v' in tag, but not here)
)

# replace <module-path> => <module-path|local-path> [version]
replace github.com/hof-lang/cuemod--cli-golang => github.com/hofstadter-io/hofmod-cli-golang v0.2.0
replace github.com/hof-lang/cuemod--cli-golang => ../../cuelibs/cuemod--cli-golang

.mvsconfig.cue allows you to define custom module systems. With some simple configuration, you can create and control and vendored module system based on go mods. You can also define global configurations.

See the custom-modder docs to learn more about writing you own module systems.

This is the current Cue modder configuration:

cue: {
  Name: "cue"
  Version: "0.1.1"
  ModFile: "cue.mods"
  SumFile: "cue.sums"
  ModsDir: "cue.mod/pkg"
  MappingFile: "cue.mod/modules.txt"
  InitTemplates: {
    "cue.mod/module.cue": """
      module "{{ .Module }}"
      """
    }

  VendorIncludeGlobs: []
  VendorExcludeGlobs: [
    "/.git/**",
    "**/cue.mod/pkg/**",
  ]
}

Want to help out?

Here are some commands if you want to develop mvs.

Make sure you have go 1.14 and cue 0.1.1 are installed. Development setup requires the hof tool as well.

# Fetch mvs code
git clone https://github.com/hofstadter-io/mvs
cd mvs

# Fetch golang deps and build
go mod vendor
go build

# Run local mvs
./mvs help

# Fetch cue/hof deps
./mvs vendor cue

# Generate code
hof gen        # Generate gocode for the cmd implementation
git status # should be no difference

You may also like to look at the hofmod-cli project. We use this to generate the CLI code and files for CI. The mvs uses our hof tool for code generation of itself and is also imported into the hof tool as both cue and go modules, embedding the mvs cli as the subcommand hof mod.

You can find us in the cuelang slack for now.

• MVS has better semantics for vendoring and gets us closer to 100% reproducible builds.
• JS and Python can have MVS while still using the remainder of the tool chains.
• Prototype for cuelang module and vendor management.
• We need a module system for our hof-lang project.

Using go modules

Go and Versioning

More about version selection