On Sun, Feb 14, 2016 at 12:50 PM Aaron Bentley <aaron.bent...@canonical.com> wrote:
> Another use case is when you want to create a charm deploys Python > code. You want it to use "resources" instead of downloading > dependencies from PyPI. > > 1. The list of resources can change over time. You don't want the > charm to have to change every time the deployed software adds/removes > a dependency. > > 2. The version numbers are embedded in the filenames. You don't want > the charm to have to change ever time deployed software changes its > version numbers. > > Yes, you can work around this with tarfiles, but why do we want to? > It's a pain to build a tar file every time a single dependency > changes. It's easier to use S3 instead for a particular use case, but > it doesn't solve the general case. > I'd push back a little bit here though. We do this in a couple of python web applications. We keep a repo of 'download-cache' which is the current pypi .tar.gz and use that built into a single download-cache tarball for deliver in the charms. This would be one resource. The second resource would then be the actual python application. It would have the makefile, requirements.txt file, source code, etc. It would depend on the download-cache file being there and so with the two, you'd manage both the source code and the dependencies as two different resource files that are all updated individually from the actual charm itself. So if a dependency is updated you can just update the source/download cache resources and not the charm. If the source code is updated and no deps are updated you just update the source code. Again, there's room to improve the idea for the 'many resources' ideas, but the current work moves things forward into a nice direction reducing the need for fat charms and allowing some flexibility.
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
