Open GuySartorelli opened 2 weeks ago
It's a nice idea. Where would you store the registration info? How would you deal with conflicts between project and global?
Where would you store the registration info?
I don't know enough about docker to know how it would work, assuming "registration info" is referring to docker. If instead you mean where would DDEV store information about what global addons it has installed, presumably that would live next to the other global files in ~/.ddev
How would you deal with conflicts between project and global?
Not sure. Maybe addons should only be allowed to be installed either globally or per-project, not both. That would be the easiest solution.
Alternatively maybe if it's installed globally the service names have a global-
prefix or -global
suffix.
None of this has anything to do with Docker, but you can look at the code that gets created in .ddev/addon-metadata to see how it works, and explore the code related to that.
None of this has anything to do with Docker
How will the docker containers installed at a project-level access the docker containers that are part of a global addon? Does that just happen without needing to do anything special?
They would need to be on the same docker network AFAIK. Not sure of the implications.
While I love the idea, I'm concerned about people sharing a ddev project confused because their experience isn't exactly the same (teammember A gets an error, while teammember B doesn't - because A has a global addon than B hasn't, and e,g. it conflicts ports)
DDEV does have a way to install commands globally, look at install.yml
file in tyler36/ddev-tinker, tyler36/ddev-vscode-devcontainer.
Spolier:
global_files:
- commands/web/tinker
This works well for generic commands that can be used for any project, or commands the are framework specific (the command won't run if the project-type doesn't make).
Problems come when you need to think about versioning and services. phpmyadmin works well for MySQL projects but I don't need it for Postgres or SQLITE projects. What do I do for a PHP 7.0 project (phpmyadmin supports PHP >=7.1)?
I recommend forking the addon, and making the adjustments and playing with it for a bit. If you still feel strongly that it would benefit as a global addon, you could then submit the changes as a PR.
Happy to help you on Discord if you hit a problem. 😄
** Update: Changed "MR" => "PR".
This isn't about installing a command globally, it's about having the docker container run globally and sharing the single container with multiple projects. For example I don't want a separate phpmyadmin instance for each project, I want a global phpmyadmin instance that connects to all my projects.
Updated the title. A classic example is PhpMyAdmin. We removed it from core because lots of people didn't need it, but those that did wanted it to be global.
Is there an existing issue for this?
Is your feature request related to a problem?
Some addons are really suitable for use across all projects, and should be sharable across them.
Take adminer and phpmyadmin for example - if DDEV had a way to install an addon globally and share its containers across all projects, I could install adminer or phpmyadmin once globally, and then use it for all of my projects. What's more, that addon would then not be included in the git repository for sharing the DDEV config, so other developers working on the same project are free to use whatever database viewer they want without wasting resources on the one they aren't using.
There are some containers that can take a while to start up as well, like elastic for example. If I could install those globally, I'd just have to start the container once and use it for all the projects I touch that day.
Describe your solution
Add a
--global
flag to theget
command. Using this flag will install the addon globally, and make any containers it adds accessible to all projects.Perhaps addons should have a new config option in the
install.yaml
file that indicates whether the addon can be installed globally, per-project, or both (with the default being either both or only per-project). If so, theddev get --list
output should be updated to display that information.There will need to be some mechanism for starting/restarting/stopping those global containers.
Describe alternatives
No response
Additional context
No response