Andrew, Good point. I opened https://github.com/juju/charm-tools/issues/84 for offline dev support.
On Thu, Dec 17, 2015 at 6:33 PM, Andrew Wilkins < [email protected]> wrote: > On Fri, Dec 18, 2015 at 9:27 AM Cory Johns <[email protected]> > wrote: > >> Andrew, >> >> It's mentioned at the start of >> https://jujucharms.com/docs/stable/authors-charm-building and there is a >> PR (https://github.com/juju/docs/pull/746) to rework the existing >> authors doc into a developer guide focused on creating charms with layers >> that will bring a lot of this information together that is currently in >> various locations. Reviews on that are welcome. >> > > Thanks, not sure how I missed that. > > As for building reactive charms offline, I'm not sure I understand the >> question. Layer and interface deps are cached under $JUJU_REPOSITORY/deps >> and after the first build the wheelhouse will be in the charm output dir >> and we could potentially prefer them over hitting the index again, but the >> first build as well as any new deps, layer, interface, or wheelhouse, will >> inherently require network access. >> > > So I wanted to build charms while on a plane without Internet access. > Maybe I was just doing something wrong, but it wanted network access > despite having fetched/built the dependencies once before. > > Obviously we'll need to hit the network on the first build, and that's > totally fine. If pip could be optionally instructed to reuse the existing > wheelhouses, that would be helpful. I'd build the charms once before losing > network, and then continue iterating with the cached dependencies. > > Cheers, > Andrew > > >> On Thu, Dec 17, 2015 at 6:09 PM, Andrew Wilkins < >> [email protected]> wrote: >> >>> On Fri, Dec 18, 2015 at 8:58 AM Cory Johns <[email protected]> >>> wrote: >>> >>>> Greetings, all. >>>> >>>> I wanted to suggest a convention for managing layered charms with >>>> Launchpad. >>>> >>>> Until the publish workflow is ready, the "built charm" (i.e., output >>>> from `charm build`) must be checked in to Launchpad in a repo such as: >>>> >>>> lp:~user/charms/trusty/foo/trunk >>>> >>>> The base path and branch are required to be charms/<series> and /trunk, >>>> respectively, for the charm to be ingested into the store. >>>> >>>> Launchpad isn't really set up to deal with charm layers, but I think we >>>> could settle on a convention of using the branch /layer to denote the >>>> source charm layer for the corresponding /trunk built charm. The source >>>> layer (under /layer) is what we would like to have submitted to the Review >>>> Queue, and the /trunk branch could be used only for ingestion into the >>>> store. >>>> >>>> Note that interface and base layers would need to have their own >>>> project, since they don't really fit into the charms/series project >>>> structure. They can also live outside of Launchpad and work just fine as >>>> long as they are registered in http://interfaces.juju.solutions/ >>>> (which can be done by anyone with Launchpad credentials) (eventually, the >>>> plan is for them to be published to the store in a similar way to charms). >>>> >>>> I'd also like to mention our recommendations for developing layered >>>> charms. Specifically, you should create a base Juju repository directory >>>> (e.g., ~/charms) and subdirectories for "layers", "interfaces" (if you plan >>>> to develop those), and any series directories such as "trusty". Then, you >>>> should ensure that the following variables are set in your environment: >>>> >>>> JUJU_REPOSITORY=~/charms >>>> LAYER_PATH=$JUJU_REPOSITORY/layers >>>> INTERFACE_PATH=$JUJU_REPOSITORY/interfaces # optional >>>> >>>> Many layer and interface repos are prefixed with "layer-" or >>>> "interface-" to indicate their role (e.g., >>>> https://github.com/juju-solutions/layer-hadoop-base) but when cloned >>>> locally to work on them, the directory name must match the layer or >>>> interface name ("hadoop-base", in this case). So, to clone that repo: >>>> >>>> git clone https://github.com/juju-solutions/layer-hadoop-base >>>> $JUJU_REPOSITORY/layers/hadoop-base >>>> >>>> This will ensure that `charm build` does the right thing, can find all >>>> of your in-progress layers, and puts the built charm in the right place. >>>> >>> >>> Is this all documented somewhere? I ended up doing almost exactly what >>> you've described here through reading the charm tools code -- would be good >>> to get it into the author's guide, I think. >>> >>> Is anyone looking at making it possible to build reactive charms >>> offline? AFAICT, you have to have access to the Internet for the pip >>> resources. And maybe the base layer? >>> >>> Cheers, >>> Andrew >>> >>> Thanks! >>>> -- >>>> 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
