That sounds like an acceptable solution, but perhaps a HTTP redirect is more elegant.
Apache: https://www.linode.com/docs/websites/apache-tips-and-tricks/redirect-urls-with-the-apache-web-server nginx: http://www.cyberciti.biz/faq/301-redirect-on-nginx-server/ 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 12:18, Anders Logg <[email protected]> wrote: > How do I set up the redirect? As of now, we have a cronjob that fetches > fenics-install.sh every 5 min from bitbucket. > > -- > Anders > > > Wed Jan 21 2015 at 12:13:42 PM skrev Jack HALE <[email protected]>: >> >> 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 _______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
