But that argument also goes for fenics-install.sh. That is also not a developer tool. The developer tools in that repository are:
fenics-install-component.sh (previously cmake.local) fenics-install-all.sh (calls fenics-install.sh to build deps and then fenics-install-component.sh for each FEniCS component) Wouldn't it be impractical for the virtual containers to depend on a script inside another repository (fenics-install-all.sh)? Or would it be calling fenics-install-all.sh via the web interface (wget | bash)? Then it might work. I think the most important points here are: 1. That the tools (HashDist scripts + virtual containers) are easy to find by users 2. That the tools can be used with minimal hassle (requiring on the order of one single command to run) 3. That if the tools depend intimately on each other, they be put in the same repository to make fixes simple Another possibility would be to find a new and better name for fenics-developer-tools or a new name for a completely new repository and throw everything in there. -- Anders Wed Jan 21 2015 at 11:36:10 AM skrev Garth N. Wells <[email protected]>: > I would favour (1) because the virtual environments/containers are not > just developer tools. > > A nice things is that containers/virtual environments and Hashdist are > complementary; Hashdist will always be a challenge because it cannot know > all the details of every system it's deployed on. Using Hashdist inside a > container means Hashdist can operate inside a well-defined and controlled > environment, and one which can be moved across platforms. I can see > containers + Hashdist being a great way for developers to test different > platforms (and debug buildbot failures). > > Garth > > On 21 January 2015 at 08:10, Anders Logg <[email protected]> wrote: > >> Good proposal. I would vote for (2) to: >> >> (i) tie the two efforts more closely together >> (ii) make development easier (I imagine a small change in one of them >> might require a small change in the other) >> >> -- >> Anders >> >> >> Wed Jan 21 2015 at 9:00:33 AM skrev Jack HALE <[email protected]>: >> >> As some of you might know, Garth Wells, Lizao Li and I have been >>> working on virtual environments for portable and reusable distribution >>> of FEniCS. This work is in garth-wells/fenics-virtual mainly under the >>> docker branch. >>> >>> The hashdist effort provides an excellent, simple and consistent >>> cross-platform way of building FEniCS. Nonetheless, I do not think it >>> provides: >>> >>> a) a really, really easy environment for absolute beginners on Windows. >>> b) a completely consistent environment for; teaching, repeatability of >>> results, cross-platform use within a research group. >>> c) a method for quickly moving the same environment from the users >>> computer to a cluster environment. >>> >>> However, I think that together the two projects should complement each >>> other nicely. >>> >>> Within the fenics-virtual project we essentially have our own set of >>> build scripts, but it seems sensible to me to re-write at least some >>> of our virtual environments to use the new Hashdist scripts. More >>> specifically, Docker stable-ppa and vagrant stable-ppa would continue >>> to use the PPA archives, and Docker developer and stable-src would >>> move to using Hashdist. >>> >>> The two options are: >>> >>> 1) Bring the re-written garth-wells/fenics-virtual under >>> fenics-project and keep fenics-developer-tools separate. Simple! >>> 2) Bring the functionality of fenics-virtual directly into >>> fenics-developer-tools. The advantage of this is that users and >>> developers can immediately see all of the ways we offer for using >>> FEniCS. The downside is it introduces complexity. >>> >>> My personal opinion is to go for option 1) for simplicity and >>> separability of the two efforts. >>> >>> Let me know what you think! >>> >>> Cheers, >>> >>> Jack >>> _______________________________________________ >>> fenics mailing list >>> [email protected] >>> http://fenicsproject.org/mailman/listinfo/fenics >>> >> >> _______________________________________________ >> fenics mailing list >> [email protected] >> http://fenicsproject.org/mailman/listinfo/fenics >> >>
_______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
