An Open Question: Charm Dependency Management

[sheila miguez]

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


-- 
shekay at pobox.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20150120/ae9fffbc/attachment.html>