Are environment-specific modules possible? Or am I seeking the wrong solution?

I’m trying to create my first theme, and at the moment I’m specifically trying to first create a future-proof foundation for any theme, before moving on to the actual theme itself. My relevant repos are:

I want to add my theme to the demo site using modules, and have this work with GitLab Pages and GitLab CI. In order to make this work with the CI, it appears I must vendor the module, which is ffine. I basically had that working, but concluded that I also wanted to be able to locally test pre-commit changes to my theme without having to first commit and push to either remote repo.

So my next thought was to split my module config into separate development and production config directories and files, with development using the local relative file path on my laptop, and production using the public GitLab.com theme repo URL. I made a disposable change to my theme locally to verify hugo server picks up the local theme instead of the remote theme (basically, in a temporary local branch, the site background is yellow; in the file pushed to the remote theme repo, the background is white).

Assuming the solution I am pursuing to testing theme changes locally without pushing to the remote is the right solution, then my main problem now is getting my git pre-push hook to work again now that I have split the module in two. You can see the hugo mod commands I have used in the sample hook file in the demo site repo. I thought from reading the docs that I could pass an --environment production flag to the hugo mod commands but that is not working. The error message is:

% git push lab master                                                                                                                           ±[master] 2760e01 [lab]
hugo: cleaned module cache for "gitlab.com/puffyn/puffyn-ht"
go: warning: "puffynDemo/..." matched no packages
go get: malformed module path "--environment": leading dash
go get: malformed module path "production": missing dot in first path element
On branch master
nothing to commit, working tree clean
error: failed to push some refs to 'gitlab.com:puffyn/puffyn.gitlab.io.git'

… followed by (on a second push attempt)

% git push lab master                                                                                                                           ±[master] 832f73d [lab]
hugo: cleaned module cache for "gitlab.com/puffyn/puffyn-ht"
Update module in /run/media/ddg/wmst/mirror_source/ABODE_EXT/Zed_Directory_Ext/Projects_Ext/hugo/sites/puffyn.gitlab.io
flag provided but not defined: -environment
usage: go get [-d] [-t] [-u] [-v] [-insecure] [build flags] [packages]
Run 'go help get' for details.
On branch master
nothing to commit, working tree clean
error: failed to push some refs to 'gitlab.com:puffyn/puffyn.gitlab.io.git'
                                                                           

I basically only want to vendor the production module that uses the path to the remote repo, while keeping GitLab CI completely unaware of the alternate development module.

Am I pursuing the best solution/workflow?
If so, then how should I update the pre-push hook file to only vendor the production module?
Or if I am overlooking a better workflow to achieve my goal of testing local theme changes without pushing them to the remote repo,any insight would be greatly appreciated.


Apart from this core issue, if you happen to notice anything else in my repos that should be changed, any insight is greatly appreciated. For instance, when I move any top-level config option out of a single config file and into a separate dir/file tree, I wasn’t sure if conventions like [[imports]] should be carried over, or changed to single-bracket variants like [imports]. I just want my theme and proto-theme foundation to be current idiomatic, best-practices correct code.

In normal circumstances git push will not call hugo. You seem to have some form of push hook going on that you need to post for us to understand the situation.

It’s in the demo site repo:
https://gitlab.com/puffyn/puffyn.gitlab.io/-/blob/master/pre-push.git-hook-sample.sh

It was working prior to my splitting the module into two separate files with separate import paths, and accordingly trying to update the hook script with an environment flag.

I just don’t want hugo mod vendor to ever select files from my local theme directory not intended for pushing; the only files I want to vendor (for the site demo repo) are theme files that were already pushed to the separate theme remote repo.

I gave up on using the vendoring method with the default GitLab CI image (necessitated by that image apparently not contained a go binary), and used an alternate image. This also rendered my git hook unnecessary. In the updated .gitlab-ci.yml , I also added an --environment production flag to the hugocommand, and the build picked up the correct module.toml, while still allowing me to use a different module.toml file for local development environment.

I don’t know if this will work anywhere else but GitLab Pages, but I’m glad it’s at least working at the moment.

I discovered a replace directive that can be placed in the go.mod file, like so
replace gitlab.com/puffyn/puffyn-ht => /home/ddg/zd/pje/hugo/themes/puffyn-ht
but then I saw I had to disable that before making a site “live” so that really just resembled my prior conundrum of constantly committing and pushing to see changes even locally. So I’m hoping using two different module.toml files in the environment-specific config directories is a good workaround for any deployment platform.