An Open Question: Charm Dependency Management

[Cory Johns]

I think that it's important that we have tooling (i.e., bundletester)
that sets up a (consistent) environment that is exactly the same as
what the automated test runner uses (i.e., a fresh container or vm in
which the tests are run) and that charm authors and reviewers alike
use it.  With that, the exact mechanism used for dependency management
(apt, sudo pip, virtualenv, bundler, juju resources, etc) becomes more
or less moot.

+1 for testing on all substrates, including manual provider (I'm
fairly sure I have some charms that would fail because I didn't
consider that)

+1 for having bundletester support both unit_test and functional_test
test targets

On Wed, Jan 21, 2015 at 1:48 AM, Kit Randel <kit.randel at canonical.com> wrote:
> On Wed, Jan 21, 2015 at 8:24 AM, Michael Nelson
> <michael.nelson at canonical.com> wrote:
>>
>> For eg., if it was a python charm that needed some python packages:
>>
>>
>> .virtualenv:
>>     virtualenv .virtualenv
>>     .virtualenv/bin/pip install -r test_requirements.txt
>>
>> test: .virtualenv
>>     ./virtualenv/bin/python ./unit-tests
>
>
> My python charm makefiles looks like this too, but one minor improvement is
> to suppress output from pip with '-q' which makes running dependant targets
> like 'test' and 'lint' much less noisy, e.g.
>
> .virtualenv:
>     @virtualenv .virtualenv
>     @.virtualenv/bin/pip install -q -r requirements.txt --upgrade
>
> --
> Kit Randel
> Canonical - Ubuntu Engineering - Continuous Integration Team
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>