[ANN] charm-tools 1.9.3

Adam Stokes adam.stokes at canonical.com
Thu Nov 26 04:52:26 UTC 2015


What if we only needed pure python modules? It seems like the toolchain
will always be installed because of some of the dependencies of
charmhelpers? Will these additional deps become optional once charmhelpers
is refactored?




On Wed, Nov 25, 2015, 11:18 PM Marco Ceppi <marco.ceppi at canonical.com>
wrote:

On Wed, Nov 25, 2015 at 4:08 PM Simon Davy <bloodearnest at gmail.com> wrote:

On 25 November 2015 at 16:02, Marco Ceppi <marco.ceppi at canonical.com> wrote:
> ## Wheel House for layer dependencies
>
> Going forward we recommend all dependencies for layers and charms be
> packaged in a wheelhouse.txt file. This perform the installation of pypi
> packages on the unit instead of first on the local machine meaning Python
> libraries that require architecture specific builds will do it on the
units
> architecture.

If I'm understanding the above correctly, this approach is a blocker for us.

We would not want to install direct from pypi on a production service

 1) pypi packages are not signed (or when they are, pip doesn't verify
the signature)
 2) pypi is an external dependency and thus unreliable (although not
as bad these days)
 3) old versions can disappear from pypi at an authors whim.
 4) installing c packages involves installing a c toolchain on your prod
machine

Additionally, our policy (Canonical's, that is), does not allow access
to the internet on production machines, for very good reasons. This is
the default policy in many (probably most) production environments.

Any layer or charm that consumes a layer that uses this new approach
for dependencies would thus be unusable to us :(

It also harms repeatability, and I would not want to use it even if
our access policy allowed access to pypi.

For python charm dependencies, we use system python packages as much
as possible, or if we need any wheels, we ship that wheel in the
charm, and pip install it directly from the there. No external
network, completely repeatable.

So, allow me to clarify. If you review the pastebin outputs from the
original announcement email, what this shift does is previously `charm
build` would create and embed installed dependencies into the charm under
lib/ much like charm-helper-sync did for instead for any arbitrary Pypi
dependency. Issues there are for PyYAML it will build a yaml.so file which
would be built based on the architecture of your machine and not the cloud.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20151126/516951ab/attachment.html>


More information about the Juju mailing list