Duplicate module

[chad-betamax]

I have the following layout:

$ tree
myproject
├── installs
│   ├── neovim.just
│   ├── ripgrep.just
│   ├── traceroute.just
│   └── xclip.just
├── JUSTFILE
├── modules
│   ├── apt.just
│   └── curl.just

Where my intention was for each of the just files under myproject/installs/ to be runnable either standalone or from the root level myproject/JUSTFILE.

The myproject/modules/*.just files have common behaviour that was to be called from anywhere.

If we look at the various files:

The root level JUSTFILE

$ cat JUSTFILE
import "installs/ripgrep.just"
import "installs/xclip.just"
import "installs/traceroute.just"

apt-installs: 
    # Update apt cache
    @apt update
    @apt autoremove

    # Installing xclip
    @just install-xclip
    @just install-traceroute

curl-installs:
    # Installing ripgrep
    @just install-ripgrep

deploy: apt-installs curl-installs

One of the ../install files (the xclip just file is identical to the below save for the name)

$ cat installs/traceroute.just 
mod apt "../modules/apt.just"

# install traceroute with apt
install-traceroute:
    @just apt::get "traceroute"

And lastly one of the modules

$ cat modules/apt.just 
# module for installing packages with apt package manager
get package:
    @sudo apt-get --assume-yes install {{ package }}

This arrangement yields this error

error: Module `apt` first defined on line 1 is redefined on line 1
 ——▶ installs/xclip.just:1:5
  │
1 │ mod apt "../modules/apt.just"
  │     ^^^

Which I'm guessing is a circular import.

Is this expected behaviour?

I can get it to work by removing the
mod apt "modules/apt.just"

import from the installs/*.just files and placing it within the root level JUSTFILE but this kills the modularity I was going for.

So am I doing it wrong and I have to rethink my approach or can I get around the circular import?

[casey]

A circular import is when, for example, a imports b which imports a again. This is a duplicate definition.

You could work around it by importing apt.just instead of making it a module. Identical duplicate imports are allowed. Or you could make your existing imports modules, since then the apt submodules wouldn't clash.

We already have allow-duplicate-recipes and allow-duplicate-variables settings, and I guess we could add allow-duplicate modules. Those settings are kind of hacks though, and I'm not crazy about adding more.

[chad-betamax]

Thanks for the clarification re the circular import.

I redid my approach - I was thinking in an Ansible-esque way and was making things too complicated.

What also tripped me up was that I found I couldn't work out the difference between modules and imports. After reading the docs I came away unclear which method would be used when.

Otherwise great work on a excellent tool!

One supplementary question - I'm now using modules and am looking to hide these from a just --list ... is this possible?

[casey]

I agree that there is a lot of duplication between modules and imports.

Imports work by conceptually inserting the referenced file into the current file. So you get a justfile that contains the recipes from both.

Modules create a new namespace which contains the recipes of the referenced files. So you can call them on the command line with just SUBMODULE RECIPE or just SUBMODULE::RECIPE. Currently though, modules are pretty gimped, you can't call recipes in a submodule, so while I think modules are cleaner from an organizational perspective, you often have to use imports due to limitations.

[casey]

One supplementary question - I'm now using modules and am looking to hide these from a just --list ... is this possible?

This isn't currently possible, but seems reasonable to: #2561.