Modules stabilization tracking issue

[casey]

This issue tracks stabilization of mod statements.

There are a bunch of features which aren't yet implemented, but I think they can all be implemented in a backwards compatible fashion:

• Recipes defined in one module can be called from another
• Variables defined in one module can be referenced from another
• Allow inline modules that are declared and defined in a single file.
• Allow submodules to opt-in to using parent module settings
• Allow submodules to opt-in to loading .env files
• Variables defined in a submodule should be overridable on the command line #2119
• Make non-compilation errors refer to modules source file
• Make just --show work with modules

I want the feature to be well used and well tested before stabilizing it.

• Recipe listing has wrong indentation when nested modules are used #1901
• Multiple use of the same import is detected as circular #1848
• Add module_file() and module_directory() functions #2105
• Improve --list output with modules #2107
• Error message incorrect when running a non-existent recipe in a module #1866

[matthewtgilbride]

Hi @casey, curious if this project is inspired to any extent by mmake? For me, the most painful thing that traditional make lacks is support for remote includes.

For example, we have built out a set of common makefiles at my job for common projects (e.g. ExpressJS/Node apps, Spring Boot apps, AWS Lambda with SAM CLI, etc.). We also have a core makefile that exports handy commands to print messages in certain colors, require certain environment variables, etc.

The most annoying part of this setup is that we have to ask people to copy/paste files into their repos. We even have an update-makefiles command so that once they do so, they can consume updates without friction.

I just wanted to throw this out there. I know there is a lot of thought being put into a module system in general, but allowing for remote modules would be awesome.

Thanks for all the hard work on a really cool tool :)

[casey]

Hi @casey, curious if this project is inspired to any extent by mmake?

I didn't know about mmake but it seems to be in a similar vein, although just pre-dates it by a couple years. In fact, just also used to be a wrapper-script around make. I've been meaning to add a list of alternative command runners to the readme for a while, so I just opened #1008 which mentions mmake.

For me, the most painful thing that traditional make lacks is support for remote includes.

That's a super interesting feature. We don't have modules, but if we ever do, I wouldn't be opposed to adding something like that.

For example, we have built out a set of common makefiles at my job for common projects (e.g. ExpressJS/Node apps, Spring Boot apps, AWS Lambda with SAM CLI, etc.). We also have a core makefile that exports handy commands to print messages in certain colors, require certain environment variables, etc.

Interesting, that does seem very useful.

I just wanted to throw this out there. I know there is a lot of thought being put into a module system in general, but allowing for remote modules would be awesome.

Feel free to open an issue about remote modules, why they're cool, how you use them. It's something that won't get implemented for a long time, but having an issue for it would probably be good.

Thanks for all the hard work on a really cool tool :)

You are most welcome! It is good to be of service 🙌

[lorengordon]

Found this issue also hoping it was talking about remote includes. We currently use make, and rely heavily on a centralized makefile. It's distributed using an include line that uses a shell command to invoke curl:

include $(shell test -f .common.mk || curl -sSL -o .common.mk http://url/to/common.mk; echo .common.mk)

Works pretty well, but some of the frustrations around make have us always looking for alternatives. Which is how I found just, and now I am evaluating whether it will work for us...

[dionjwa]

I would also jump in with support for remote modules.

One of the hardest things about working with cloud infrastructure and deploying applications is the need for sharing and reusing.

Wanting to reuse all these great just commands I've written in one repository are not easily transferred to another repository.

I feel like deno has solved this problem (URL imports, versioned, immutable repos), and aim to write all my future cloud related coordination and scripting.

But it doesn't get around not being able to re-use just commands where I really want them.

I think this tool really appeals to those who pipeline software.

[stereobutter]

I'd love to have something analogous to url imports in dhall for importing modules in just. A simple solution without caching or checksums would be enough for my needs. I'd likely use commit hashs/tags for versioning and whether or not a 50ms http request is cached or not doesn't matter to me.

Fetching from private repos is probably a more important feature and requires some though in the general case, for github nothing special is required as one can just put the personal access token in the url.

Importing from public repo:

keybase := import https://raw.githubusercontent.com/casey/just/v0.9.4/examples/keybase.just 

Importing from private repo

foo := import https://{{TOKEN}}@raw.githubusercontent.com/some_org/some_private_repo/v0.1/foo.just 

where TOKEN is either supplied via the command line or via environment variable.