Support symlinks for developing

[fsackur]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• [/] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• [/] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Is your feature request related to a problem? Please describe.

I'm developing a plugin. But it's important to me to have a low-friction workflow.

I have started by installing from ISO, then I have symlinked content from my git repo into /usr/. This lets me dev on a live system without endlessly running sync commands.

Templating fails:

# sudo service configd restart
Stopping configd...done
Starting configd.

# sudo configctl template reload OPNsense/OpenApi
ERR

This is because my symlinked template folder is not picked up by os.walk in Template.list_modules() - https://github.com/opnsense/core/blob/c9b8f41/src/opnsense/service/modules/template.py#L122

Describe the solution you like

• add the followlinks=True argument in template.py
• example: https://github.com/opnsense/core/compare/master...fsackur:opnsense_core:symlinks?expand=1
  • LMK if you'd be willing to review, and I'll open the PR
• worth discussing? add my symlink script to docs for the benefit of plugin developers

Describe alternatives you considered

• rsync files from git into /usr/ (I will probably mess up and overwrite my index several times)
• hard links (I am not easily able to distinguish them to clean up)
• put the entire /usr/local/opnsense into git and unfuck it in the repo before PR (extra work)
• build opnsense from source (not otherwise necessary for my use case)

Additional context

symlink script

# TODO:
# - accept arguments for plugin name
# - calculate the git repo folder from $0
if [[ ! -d "/app" ]] ; then

ln -s /usr/local/opnsense/mvc/app /app  # convenience

fi
for folder in "controllers" "models" "views"; do

if [[ ! -d "/app/$folder/OPNsense/OpenApi" ]] ; then

pushd "/app/$folder/OPNsense"

ln -s "/gitroot/opnsense/plugins/devel/openapi/src/opnsense/mvc/app/$folder/OPNsense/OpenApi"

popd

fi

done
if [[ ! -d "/usr/local/opnsense/service/templates/OPNsense/OpenApi" ]] ; then

pushd /usr/local/opnsense/service/templates/OPNsense/

ln -s "/gitroot/opnsense/plugins/devel/openapi/src/opnsense/service/templates/OPNsense/OpenApi"

popd

fi
if [[ ! -f "/usr/local/opnsense/service/conf/actions.d/actions_openapi.conf" ]] ; then

pushd /usr/local/opnsense/service/conf/actions.d/

ln -s "/gitroot/opnsense/plugins/devel/openapi/src/opnsense/service/conf/actions.d/actions_openapi.conf"

popd

fi
if [[ ! -f "/usr/local/opnsense/scripts/OPNsense/OpenApi" ]] ; then

pushd /usr/local/opnsense/scripts/OPNsense

ln -s "/gitroot/opnsense/plugins/devel/openapi/src/opnsense/scripts/" OpenApi

popd

fi

[AdSchellevis]

Different people use different workflows, but if supporting symlinks eases yours, I don't mind having a look at a PR, there isn't a strict reason to not support them as far as I know.

[fichtner]

IMO "make install" and "make collect" are as powerful as they get for development as long as you adhere to a core and plugin structure. Symlinks will create other problems, e.g. when numerous scripts test -f or -d.

[fsackur]

I appreciate the feedback and the welcome you have offered. Maybe it's not a good idea to PR. Any other dev that finds this issue can follow my footsteps.

Happy to close this issue - I guess it will be closed for inactivity if no-one else weighs in.