For the short term, yes, you can copy the file to somewhere in the charm. In the long term having this code ported to the new charm-helpers and making it available via the CLI module so that more charms can leverage this would be ideal.
Thanks, Marco Ceppi On Fri, Nov 8, 2013 at 6:28 PM, Jason Hamilton <[email protected] > wrote: > Marco, > > That actually makes a lot of sense. I think I will use that method you > mentioned. I assume the best way is to just copy, paste and modify your > code directly in the charm? > > Jason > > > On Fri, Nov 8, 2013 at 3:12 PM, Marco Ceppi <[email protected]>wrote: > >> Hi Jason! >> >> This is very much an important issue to resolve, however I feel that a >> subordinate charm is something that would require more effort on the users >> part and we don't want to burden the user if we can avoid it. I think where >> this can be fixed and addressed is in charm-helpers, which is a project >> designed to solve common problems in repeatable ways for charm authors. In >> the first version of charm-helpers, there was a solution written in Bash to >> address common DVCS tools: >> http://bazaar.launchpad.net/~charmers/charm-tools/trunk/view/head:/helpers/bash/vcs.bash >> This >> version of charm-helpers is being deprecated, recent release of charm-tools >> have removed this code, and efforts are centered around lp:charm-helpers >> instead. At this time, the above functionality hasn't been ported, in >> addition the new charm-helpers project is currently geared at Python charms >> (with a lot of work being done now to make it available to all languages >> via a generic "programmable interface"). >> >> I'd start by implementing the logic so that a charm author needs only >> call `fetch_from_remote $(config-get config-key-for-charm) /path/to/store` >> where that config-key could be a file fetched via HTTP, a code repository, >> etc. That way for a charm author it's trivial to add support for all these >> methods and the heavy lifting can be unit tested and provided for all >> charms across the board. >> >> Thanks, >> Marco Ceppi >> >> >> On Fri, Nov 8, 2013 at 5:52 PM, Jason Hamilton < >> [email protected]> wrote: >> >>> So, I've been browsing the charms lately and it looks like a lot of >>> charms use a VCS (git, bzr, svn, etc). When I have been designing charms, >>> I like to pull from a VCS and I prefer Git. I realize that the charms I >>> want to use don't have a Git options. Also the charms I make, I only offer >>> Git. So my thinking is that it would be nice to create a VCS relationship >>> that allow a service create a subordinate VCS charm, which pulls from a >>> repository and updates it. The parent charm can just expose a folder to >>> pull to. I really think this would help with the modularity of the charms. >>> >>> >>> Take for example the LAMP charm. It only uses Bzr for its repo. What >>> if it just required a VCS charm, that way I can use whatever I want (git, >>> bzr, svn, ftp, http, S3, etc). Is there anything like this already? What >>> do you think about this? Any feedback would be appreciated. >>> >>> Jason >>> >>> -- >>> Juju mailing list >>> [email protected] >>> Modify settings or unsubscribe at: >>> https://lists.ubuntu.com/mailman/listinfo/juju >>> >>> >> >
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
