avoiding overlay of production and development denvs

[tomeichlersmith]

I've seen the following confusion happen frequently (at least twice to my knowledge over the last few weeks which is too high in my opinion). The person ends up in a state where their filesystem looks like

- path/to/ldmx/
  - .denv/      # development denv created by running just init
  - ldmx-sw/
    - .denv/    # production denv created by running denv init ldmx/pro:<version> within ldmx-sw

This leads to the very confusing situation where denv fire can work from within ldmx-sw even if its not built (since it reads from the production image denv) while just fire will not work since it is using the development image and ldmx-sw is not built yet.

Short-Term Solution

If you find yourself in this state, delete the production image denv within ldmx-sw and (if you still need it), re-create it in another directory.

rm -r ldmx-sw/.denv
mkdir my-other-project
cd my-other-project
denv init ldmx/pro:<version>

Long-Term Solution

The solution is to keep these two denvs separate. Literally any other directory other than ldmx-sw can be used for the ldmx/pro denv so maybe this can be resolved by updating the notes on the website to emphasize this point?

We could update the init recipe to specifically make sure that no denv is already created erroneously within ldmx-sw.

ldmx-sw/justfile

Lines 85 to 100 in 6c08a49

	# initialize a containerized development environment
	init:
	#!/usr/bin/env sh
	# while setting the denv_workspace is helpful for other
	# commands that can assume the denv is already initialized,
	# we need to unset this environment variable to make sure
	# the test is done appropriately.
	# just makes sure this recipe runs from the directory of
	# the justfile so we know we are in the correct location.
	unset denv_workspace
	if denv check --workspace --quiet; then
	echo "\033[32mWorkspace already initialized.\033[0m"
	denv config print
	else
	denv init --clean-env --name ldmx ldmx/dev:latest ${LDMX_BASE}
	fi

I'd like to avoid a hardcoded check within denv since I use it for other (non-LDMX or ldmx-sw) projects. Another idea is to avoid keeping the development denv outside of ldmx-sw. This choice is a relic of the ldmx suite of bash functions and could be avoided with how denv is designed. Putting the ldmx-sw denv within ldmx-sw would then help avoid this issue - you would need to overwrite the denv in ldmx-sw to get into a broken state like this and denv warns you before you would do so.

[tomeichlersmith]

For the medium term, I've added a warning to the getting started area informing anyone getting started to avoid running denv init within ldmx-sw itself.

LDMX-Software/ldmx-software.github.io@ca56d1f

[tvami]

I'm cross posting from #1505 (comment)

This happened to one of my new student now

In the long term, we should decide if this is a workflow that should be supported. Having denvs within one another can easily lead to confusion since cd .. can change which denv is chosen to run. If we do want to support this workflow, then we would want to pass the prompts that denv issues to the user so they are at least acknowledging that they have nested denvs.

What I'd like is to have a warning that there is a .denv above, and the option to get rid of it.

This is what he saw

cd /home/henry/ldmx/noise_study/ldmx-sw/
just init 
/home/henry/.local/bin/denv: line 495: /home/henry/ldmx/noise_study/.denv/config: No such file or directory
error: Recipe `init` failed with exit code 1

while he had a .denv in

cd /home/henry/ldmx/.denv/

Deleting /home/henry/ldmx/.denv/ made it work, but it would be good to streamline this for newcomers