Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Global addons for containers that can be shared (like PhpMyAdmin) #6145

Open
1 task done
GuySartorelli opened this issue May 1, 2024 · 8 comments
Open
1 task done

Comments

@GuySartorelli
Copy link
Collaborator

GuySartorelli commented May 1, 2024

Is there an existing issue for this?

  • I have searched the existing issues

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 the get 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, the ddev 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

@rfay
Copy link
Member

rfay commented May 1, 2024

It's a nice idea. Where would you store the registration info? How would you deal with conflicts between project and global?

@GuySartorelli
Copy link
Collaborator Author

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.

@rfay
Copy link
Member

rfay commented May 1, 2024

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.

@GuySartorelli
Copy link
Collaborator Author

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?

@penyaskito
Copy link
Member

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)

@tyler36
Copy link
Collaborator

tyler36 commented May 7, 2024

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".

@GuySartorelli
Copy link
Collaborator Author

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.

@rfay rfay changed the title Global addons for containers that can be shared Global addons for containers that can be shared (like PhpMyAdmin) May 10, 2024
@rfay
Copy link
Member

rfay commented May 10, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants