Suggestions to simplify the installation process

[tharris]

1. It would be useful if the installation process could be run in a non-interactive mode, reading either a file or environment variables for install paths. This would greatly facilitate scripted installs - just check in a configuration file into your app's version control, source it, then install GBrowse (for example). Perhaps it can already do this via the .def file it writes?
2. I think the install should be changed to NOT assume root privileges are available, and to encourage installation into unique non-privileged paths for each version. This would alleviate many problems that people have with library conflicts.

[leto]

+1 to both

[rdhayes]

On Fri, Jun 8, 2012 at 9:15 AM, Todd Harris < [email protected]

wrote:

1. It would be useful if the installation process could be run in a non-interactive mode, reading either a file or environment variables for install paths. This would greatly facilitate scripted installs - just check in a configuration file into your app's version control, source it, then install GBrowse (for example). Perhaps it can already do this via the .def file it writes?

Some quick notes on this for list discussion. I could also use this feature, as we make regular installations of GBrowse. I have an installation BASH wrapper script that sets the command line parameters to Build.PL and controls the compilation and install calls. I've otherwise been surviving on a slight hack of GBrowseInstall.pm that turns off user account database setup and the apache restart attempt in ACTION_install(), neither of which are necessary for my particular custom install. This is functional, but requires that I mess with the source tarball at each new release...

1. I think the install should be changed to NOT assume root privileges are available, and to encourage installation into unique non-privileged paths for each version. This would alleviate many problems that people have with library conflicts.

---

Reply to this email directly or view it on GitHub: https://github.com/GMOD/GBrowse/issues/14

Richard D. Hayes, Ph.D. Joint Genome Institute / Lawrence Berkeley National Lab http://www.phytozome.net

[cybersiddhu]

Few more comments

• For installation of gbrowse2 and without system privileges, dependency on apache needs to be decoupled. One way would be to support plack as described by @tharris here. I also wrote a mildly modified version of it (here)[https://github.com/dictyBase/GBrowse-PSGI/wiki/Running--a-PSGI-compatible-gbrowse2). It runs from a completely sandboxed environment using perlbrew and cpanm. A version of it is already deployed in our staging server running on nginx.
• For Build.PL, there could be bunch of ways.
  1. Add an extra action, say auto_install and it will assume some default location which of course could be modified by standard Build.PL option such as ./Build auto_install ---opt1= --opt2=.... . This would probably will not mess around with the existing process.
  2. Reduce the use of env variables, add those options directly in the Build.PL file or delegate that to a config file(yaml/json etc)
• The other thing i tried (from the fork of @tharris) to write a direct Plack [handler](https://github.com/cybersiddhu/GBrowse-PSGI/blob /feature/psgi_support/lib/GBrowse/Handler/PSGI.pm) instead of wrapping with CGI. It passed all the modified unit test, but i couldn't get the display working. Probably it needs more time and also might sways away too much from the upstream.

So, if there is some interest i would like to offer my help for a psgi based port of gbrowse.

[ypandit]

:+1:

[epaule]

I am also not the biggest fan of the automatic restarting of the apache. I would rather have that handled outside of the GBrowse install. On the same note, I would like to have the calls to sudo reduced, as sometimes you don't have access to sudo, and the s/sudo//g gets old quickly.