Indeed! My idea was to call fenics-install.sh from the web interface on fenics-project.org using curl.
Or, perhaps to ensure repeatability of virtual builds, I would curl/wget it from the raw file interface on bitbucket where we can ask for a specific commit of fenics-install.sh. Infact, might I suggest that instead of placing fenics-install-all.sh directly on the webserver, it might make sense for fenics-project.org to return a HTTP 303 to the raw file on bitbucket. Then there is no disconnect between the repository and the website version. You could also specify a known working commit or branch this way. So that will be the 'stable' version. Jack ----- Dr. Jack S. Hale Marie Skłodowska-Curie Postdoctoral Fellow University of Luxembourg Campus Kirchberg G005 Phone +352 44 66 44 5236 [email protected] Latest publications and conferences: http://goo.gl/rNiISG ORCID: http://orcid.org/0000-0001-7216-861X Google Scholar: http://scholar.google.com/citations?user=Fx9lQ7MAAAAJ&hl=de On 21 January 2015 at 11: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. > > 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
