Nested or sub modules

My problem appears to be a duplicate of this thread

I just don’t understand the answer - is it possible to import a module, into a module?

Just like that thread, my nested module is not showing up in _vendor or hugo config mounts.

Thanks for your help

So, just like in that thread, what is the output of hugo config mounts. What is the content of the configurations of all three modules. Can you put a sample repository online.

The short answer is that yes, you can use nested modules (import a module that itself imports modules). (I’m going that with one of my repos at this very moment). @davidsneighbour’s questions will help figure out what is going wrong, but it’s not simply nesting that is the problem.

Thanks x 2 for your quick responses. I will put together a quick response now that I know that its possible.

so here is the example:
GitHub - powerfulwebdesign/test-site: site for modules test - imports the module below
GitHub - powerfulwebdesign/test-theme: ananke clone for modules test - imports the module below
…/test-nested-module - imports 2x icon repositories

You should be able to just clone the top one, run “hugo mod get -u ./…”
and see that the icon repositories (from config in test-nested-modules) don’t show up in “hugo config mounts” and in go.mod, only test-theme is listed.

I’m not claiming this is the core of the issue, but you should start by fixing this:

The TOML spec says that only maps can follow maps, so any module config needs to be below the top level config options.

Thanks for pointing that out. I have fixed it in the repository.

I still cant get the config files to merge and have all of the modules together in the parent module (test-site).

I’m having the same issue in two other sites, they are a bit messy to share.

The typoed icons probably don’t help…

Continuing to look…

Are and also modules? if not that might be the issue.

Although I do successfully see (with the above fixed) hugo server working in

Is the main problem that the vendoring doesn’t bring everything up to the top-level site? If that’s the case I would also modularize the bootstrap and font-awesome repos

I am trying to add them as modules so they they can be accessed in “test-site”.
My problem is the config for these nested modules doesn’t seem to be filtering down to “test-site”

First, to clarify: you want and to be modules, correct?

If that is your intent you need to actually fork the repos and make them hugo modules.
(That is hugo mod init and any config.toml (or equivalent).

AFAIK pulling in a non-module repo as a module won’t work, at least not with hand-coded ‘mounts’. It might work in a ‘pure import’ scenario, but I’m not sure.

I’ve run into this myself where I tried to import non-module and it just did not work.

I’ll see about a full demo soon.

I’m remembering now that I’m working on it, is that part of the issue is that go modules have specific expectations about versioning (tags). Will post more later.

Also, because you have an ‘assets’ source mount you won’t see sources below ‘assets’, IIRC, within that repo. (with hugo config mounts). Order may matter.

The dependency modules don’t need to be Hugo Modules.

Have a look at my sample setup: [demo here]

Main repo: GitHub - pointyfar/hmd-main imports:

My main repo _vendor/modules.txt looks like this:

# v1.0.2
# v1.0.4
# v4.28.0+incompatible
# v4.7.0+incompatible
# v1.4.0
# v0.0.0-20210305201541-f26b871321a1
# v1.0.0

Other than the repos under my own name, the other dependencies are not Hugo Modules.

Have you also tried the marked solution in the other topic you linked to?

Your nested module config.yaml is inside a config dir. It must not be inside a config dir.

1 Like

Hmmm… I was wrong on that. I have more testing to do, I guess. (I’ve had trouble with non-Hugo modules in the past, but it’s probably something else that was going on, given that it works for you).

If enabled, any module configuration file, e.g. config.toml, will not be loaded. Note that this will also stop the loading of any transitive module dependencies.

I believe this is what is messing you up. I see why given font-awesomes’s defaults, but I will have to check @pointyfar’s repo to see how they handle it.

So here is the real problem:

You are pulling v4.7.0 but wanting /svgs which was introduced in 5.6.0 of FortAwesome/Font-Awesome:

You need to to do hugo mod get -u (or the version you actually want).

In addition to what was mentioned about not using config directory but config.yaml in your lower level module.

To see why hugo mod get -u ./... doesn’t automatically get the latest version of that repo see:

The @5.15.3 thing reminds me of what the problem was with non-Hugo (non-Go) modules – hugo mod get -u ./… will consistently fetch the wrong version of font-awesome in the current circumstance. The only way to fix that issue is to fix the tags in the repo you use to be compatible with Hugo/Go modules (I think it would be enough to eliminate all the vx.x.x tags from the repo, and just used the latest master). Go version module versioning is a pain especially with non-Go repos.

1 Like

Thanks so much for providing the example. I’ll have a good look through it - looks similar to what I’m trying to do.

Thanks to everyone who has replied.

I have moved the “test-nested-module” config file into the root of the site.
I have manually updated the font-awesome repository specifying the non-standard version.

It’s finally working. I realised that I didn’t understand the solution in the previous issue.

I’ll note it in the docs so its clear that only the top level site can use a config DIR.

1 Like

Thanks for the help.

Have you personally had any luck with (local) module replacements via the config files?
I can see that the path needs to be relative to the theme directory, but when modules are nested, I am assuming that the path is being resolved relative to the parent site module rather than the nested module.

FWIW using the HUGO_MODULE_REPLACEMENTS environment variable works for me (with absolute paths). I know it’s not quite what you asked, but I am not a fan of committing local paths into repos, so I never use the config file replacements.