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
Just a few other thoughts I had while working with the tool:
I think it doesn't make sense to fix the port number in the profile config. If one has something else running on port 8888 (typically Jupyter notebook), things get confusing. Maybe we should perform an automatic port check the same that the Jupyter notebook does?
Wouldn't it make more sense to keep the container name in the config? Users might want to change it.
The text was updated successfully, but these errors were encountered:
I think it doesn't make sense to fix the port number in the profile config. If one has something else running on port 8888 (typically Jupyter notebook), things get confusing. Maybe we should perform an automatic port check the same that the Jupyter notebook does?
The port is currently fixed for the default configuration, however setting it to an empty value (port = "") will have docker choose a port automatically. If I understand correctly, that would be your preferred mode? It would mean that the port would change on every start/restart.
Wouldn't it make more sense to keep the container name in the config? Users might want to change it.
The container name is determined from the profile name and a hard-coded prefix. This is how the tool is able to automatically identify the associated container and volumes (similar to how docker-compose does this).
It seems to me that adding the ability to change the container name would introduce a lot of complexity (e.g. one would have to prevent users from doing so while the container is running) without much benefit. Why exactly would a user want to change the container name?
Based on my experience I think the current status quo is okay. Having a variable port on each startup would be very confusing, and would break browser URL bar autocompletion that I am relying on when connecting remotely to Aiidalab.
Just a few other thoughts I had while working with the tool:
The text was updated successfully, but these errors were encountered: