On Tue, Apr 29, 2014 at 1:56 PM, Alan Conway <[email protected]> wrote:
> On Mon, 2014-04-28 at 15:43 -0400, Rafael Schloming wrote: > > On Mon, Apr 28, 2014 at 3:10 PM, Alan Conway <[email protected]> wrote: > > > > > I would expect things to work "out of the box" if I install proton > under > > > the same prefix as python/ruby/whatever. I would expect to have to set > > > PYTHONPATH if I install proton somewhere else (are people really > > > confused by that?) > > > > > > Yes they are. What confuses people is that when you have /usr/bin/python > > and /usr/local/php, one works "out of the box" and the other doesn't. > That > > makes it look like they were both supposed to just work and it gets filed > > as a bug. > > Gah! I finally understand what you are getting at. It sucks, but I get > it. > > > I would never expect to set something called > > > SYSINSTALL_BINDINGS and have the installer put some stuff under my > > > prefix and other stuff under /usr, or have a big scary warning in my > > > face suggesting that the software won't work if I don't do so. > > > > > > > The point of the big scary warning is that the behaviour is changing, not > > that people should feel obliged to use SYSINSTALL_BINDINGS. If you don't > > like it you're free to pretend it doesn't exist. The warning will go away > > for the next release anyways. > > > > > > > Agreed that python is a pain with its version numbers in the > site-config > > > path but I think we can get rid of SYSINSTALL_BINDINGS, simplify the > > > installer and make everybody happy as follows: > > > > > > 1. install into fixed location <prefix>/<lib>/proton/bindings as we do > > > already > > > 2. if <prefix>/bin/python exists, also install into it's site-config > > > location. NOTE: *<prefix>*/bin/python NOT /usr/bin/python or whatever > > > python is on the PATH. > > > > > > > Installing the same files into two locations isn't particularly great, > > however we have already discussed doing (2) via symbolic links. > > > > I'm pretty opposed to getting rid of SYSINSTALL_BINDINGS though not only > to > > avoid spurious bug reports, but also because it is the only foolproof way > > we have to get someone up and running quickly that isn't highly dependent > > on their system configuration. The install instructions are pretty much > > just: > > > > cmake SYSINSTALL_BINDINGS=ON > > make > > sudo make install > > > > Having this level of simplicity is A) quite useful for people who just > want > > to try things out and B) makes it a lot simpler to test in a wide variety > > of different environments. If you can come up with build behaviour that > > facilitates a README that is as simple or simpler than the above then I'd > > be happy to kill SYSINSTALL_BINDINGS. > > > > Gahhh! I can't. I'll keep trying. However I do think that if people > don't use SYSINSTALL_BINDINGS then we should respect the <prefix>, as I > proposed above. E.g. suppose I > have /usr/bin/python, /usr/local/bin/python and I do > > cmake CMAKE_INSTALL_PREFIX=/usr/local > make > sudo make install > > The we can and should install under /usr/local...site-config regardless > of what is in the PATH. If SYSINSTALL_BINDINGS is specified then we go > for the PATH. > I'm not sure exactly what would happen in the scenario you describe. I haven't done any testing on systems with two versions of the same interpreter. One thing to keep in mind though is that it doesn't make sense to build against one interpreter and then install into the site packages directory of another one. For example if in your scenario we ended up building against whatever cmake detects (probably the python that is in the path) and then installing into the site packages directory of the other interpreter, then the swig module might not work as the two python interpreters aren't guaranteed to share the same ABI for C extension modules. (They may be the same if they happen to share the same version, but most likely if you have two python interpreters installed it is because you want a different version than the one the system offers.) The logic behind installing into <prefix>/<lib>/proton/bindings by default is that it is guaranteed not to be owned by any other software, and from there you can either explicitly add stuff to your PYTHONPATH or simply link into the appropriate site-blah directories to get stuff to automatically load. As an aside, in most real scenarios using PYTHONPATH (or its equivalent) isn't a particularly attractive option even if you know how to do it. I was working on a demo a while back where one element was a linux machine with apache, mod-php, activemq, and qpid all installed. There were three or four people actually working on the demo also, and it had components in ruby, python, and php. Now because apache, active, and qpid all run as distinct users, and the three or four people developing on the system also had separate user accounts, if your only recourse is to use PYTHONPATH, LD_LIBRARY_PATH, RUBYLIB, etc, then you end up with four or five different environment variables that you need to set for 6 or 7 users, including going in and messing with the config for system accounts like the apache, activemq, and qpid user accounts, and you need to do this again everytime you add a new user (or possibly a new software component) to the project. It all gets a whole lot simpler and more manageable if you can simply install into the interpreter's site-packages directory and have everything pick up the new extension module by default. I'd venture a guess that the demo scenario isn't really all that different from what a typical proof of concept might look like for someone validating qpid software as an infrastructure choice, so I think it's worth enabling in a pretty seamless and easy way. --Rafael
