On 21 January 2015 at 10:42, Anders Logg <[email protected]> wrote:
> 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. > > It would be nice if a user of a container/VM sees as few files as possible, so I had in mind that a container could use git to clone Hashdist, etc. 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. > > A container won't only offer from source builds. In cases like teaching it's much better if the container uses apt-get because it's much faster. If the tools are not primarily for developers (which I presumed they were), then the repo should probably be re-named. With the right name, the Docker/Vagrant scripts could be added. Garth > -- > 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
