Open johnsca opened 8 years ago
axw
commented
8 years ago Combined with local provider (and presumably a local apt cache), this would allow iterative development even after network connectivity is lost (such as continuing to develop while on a plane).
Yep, FWIW I'm using the lxd provider with apt-proxy pointed at a local squid-deb-proxy.
marcoceppi
commented
8 years ago +1
From watching debug output it seems deps are fetched every time unless they first exist in INTERFACE_PATH and LAYER_PATH, see https://github.com/juju/charm-tools/issues/53
Evaluating if wheelhouse/<dep>.tar.gz version fits the dep defined in wheelhouse.txt would seem to address the source wheelhouse generation portion.
Since there are a few other network commands, an --offline flag might be good as a way to advertise no lookups should be made and to make the user explicitly acknowledge that they're doing offline builds.
johnsca
commented
8 years ago Well, we actually want the deps re-evaluated every time by default, to pick up new versions when rebuilding. However, supporting an --offline flag is a good idea.
bloodearnest
commented
8 years ago Another issue here is the virtualenv creation, which by default will install pip and friends from pypi. If --offline is specified, we could add --no-download flag the the virtualenv creation?
Layer and interface deps are cached, and the target wheelhouse could be reused or a copy kept in $JUJU_REPO/deps like for the layers and interfaces. Checks for new versions could just warn if they fail, or even be disabled entirely with a flag.
Combined with local provider (and presumably a local apt cache), this would allow iterative development even after network connectivity is lost (such as continuing to develop while on a plane).