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 < charles.but...@canonical.com> 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 <charles.but...@canonical.com> - Juju Charmer > Come see the future of datacenter orchestration: http://jujucharms.com > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/juju >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
