A Makefile that has a target to install dependencies suffices, but I think suggested conventions are still helpful. For example, in my case I prefer python virtualenvs over system packages.
Once you establish some conventions (perhaps even just documentation conventions), A charmer can document the approach taken so that devs will be aware and can take measures. e.g. if I want to make a MR to a charm that needs system packages, I will know to do my development and testing inside of a container. On Tue, Jan 20, 2015 at 11:58 AM, Marco Ceppi <[email protected]> wrote: > I don't see how a Makefile in a charm doesn't resolve this issue. As long > as we define what targets a user should create in the Makefile, the > Makefile can then do everything required: create a virtualenv and install > deps, install ruby and execute bundler, npm for node, etc. Since charms are > so varies in how they're written and what language they're implemented in > this seems to make the most sense. > > Marco > > On Tue Jan 20 2015 at 12:37:00 PM Charles Butler < > [email protected]> wrote: > >> Greetings, >> >> If you work on charms in any capacity: this affects you, and I would love >> to have your feedback. >> >> While working the review queue I've encountered a few charm merges that >> are failing our testing infrastructure due to missing dependencies. This >> also has implications that reach beyond our testing infrastructure: Anyone >> that is submitting a new charm, Patches being accepted to existing charms, >> and even our documentation efforts over on the Charm Authorship Docs. >> >> There seems to be a bit of confusion about what the recommended process >> is to ensure all our dependencies are encapsulated in the charm. >> >> Having spoken with various members of the development community, I feel >> like our dependency encapsulation process for charms is still very much a >> grey area with several different ideologies on how to manage them, thus far >> I've seen: >> >> - A Virtualenv per project to manage python dependencies >> - make targets that sudo install packages on the host system >> - Zero Dependency management >> >> This is indeed a difficult topic to approach and digest as we're >> supporting basically everything out there. Not everyone uses the same >> tool-chain to accomplish the goal of dependency isolation - and several >> different Config Management tools have a different approach to this that >> assume it is installed on the host. this leaves a broken experience for: >> >> - new charm authors >> - CI >> - Anyone that comes along and runs the test targets or bundletester >> >> If we're going to ask our community to contribute to charms, is it fair >> to make them run down dependencies that may or may not exist on their host? >> It seems like we can do a better job of highlighting this, and providing a >> quick start style development target to install these pre-deps which would >> satisfy CI and Development. With this being the proposal, I follow it with >> some questions: >> >> - How have *we* solved this problem in other areas of our ecosystem? >> - How have other platforms solved this problem? >> - Can we emulate / improve on that pattern? >> - If a package management solution exists for a technology (eg: >> virtualenv for python, bundler for ruby, npm for node, berkshelf for chef) >> - can we adopt these and get started by templating in the dependency >> management into the charm generator template? >> >> >> I'm hoping this email is seen more as a conversation starter vs me being >> pedantic - I'm more concerned with getting the right set of information to >> our users/community than I am in solving some meta problem of packaging >> charms and their Development Environments. >> >> -- >> All the best, >> >> Charles Butler <[email protected]> - Juju Charmer >> Come see the future of datacenter orchestration: http://jujucharms.com >> -- >> Juju mailing list >> [email protected] >> Modify settings or unsubscribe at: https://lists.ubuntu.com/ >> mailman/listinfo/juju >> > > -- > Juju mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > > -- [email protected]
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
