You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
I cannot count how many times I've (accidentally) deleted my 'persistent' paths before as I'm always tempted to have those mapped folders within my project directory structure for tidiness reasons 😬
That's clearly my mistake above anything else but this also made evident some of the hidden benefits of docker volumes. I was wondering if we could get something similar.
Describe the solution you'd like
The solutions I propose is to use the ~/.singularity/volumes as the default location to store named volumes.
This location could be overridden using a env var (let's say SINGULARITY_VOLUMES_PATH).
The creation process would be something like singularity volume create|remove <volume_name>
And last but not least, when the user specified a bind path, if the name matches with an existing named volumes, it would map it to the location where the named volume resides like singularity run --bind <volume_name>:/my/path
Describe alternatives you've considered
I initially considered adding this feature to singularity-compose but it was suggested to me that maybe having this feature in singularity could be a better fit for the problem.
I was wondering if there is any interest in having such feature or if this is a no-go type of feature for whatever reason. I'm keen to assist on the development of that if necessary.
The text was updated successfully, but these errors were encountered:
I have never used docker volumes before. According to what I read in the docker documentation it uses the same -v and --mount options as bind mounts. It's not clear to me how docker differentiates between them. Is it just the fact that the first parameter doesn't start with a slash (with named volumes)?
It's not clear to me how docker differentiates between them. Is it just the fact that the first parameter doesn't start with a slash (with named volumes)?
yep, you got that correctly. If the path doesn't start with /, Docker sees that as a volume and if it's already created, then it simply binds it to the container. If the volume doesn't exist yet, docker creates it first before binding it to the container.
Singularity repo is now retired as the code base is now moved to Apptainer. We are closing all the old issues under the old Singularity repo. For further assistance please open a new issue under the new Apptainer repo. Thanks for your support.
Is your feature request related to a problem? Please describe.
I cannot count how many times I've (accidentally) deleted my 'persistent' paths before as I'm always tempted to have those mapped folders within my project directory structure for tidiness reasons 😬
That's clearly my mistake above anything else but this also made evident some of the hidden benefits of docker volumes. I was wondering if we could get something similar.
Describe the solution you'd like
The solutions I propose is to use the
~/.singularity/volumes
as the default location to store named volumes.This location could be overridden using a env var (let's say
SINGULARITY_VOLUMES_PATH
).The creation process would be something like
singularity volume create|remove <volume_name>
And last but not least, when the user specified a bind path, if the name matches with an existing named volumes, it would map it to the location where the named volume resides like
singularity run --bind <volume_name>:/my/path
Describe alternatives you've considered
I initially considered adding this feature to
singularity-compose
but it was suggested to me that maybe having this feature insingularity
could be a better fit for the problem.singularityhub/singularity-compose#50
Additional context
I was wondering if there is any interest in having such feature or if this is a no-go type of feature for whatever reason. I'm keen to assist on the development of that if necessary.
The text was updated successfully, but these errors were encountered: