I often need to install software in an environment that's different from where it's going to be run, e.g. I install it on a file server, where the target directory is/export/apps/stow/, and then I use "stow" to put it in/export/apps, which clients mount as/usr/site, so they see "/usr/site/bin/", and are set up to look in/usr/site/lib for libraries, and so forth.
I don't know if this is instrinsic to newer build schemes or not, but my recent experience has been that "old-style" (autotools-based) packages
I've run into the same problem with cmake. I don't really have that problem with python tools as python's virtual environment tools [python.org] seem to handle things nicely. Tools such as pip [python.org] natively handle virtual environments, automatically installing into it when one is active.
Also, there are lots of nice wrappers [python.org] to work with python's tools, for developers, such as gogo [bitbucket.org].
by Anonymous Coward writes:
on Monday September 27, 2010 @06:48PM (#33717410)
"I don't really have that problem with python tools as python's virtual environment tools seem to handle things nicely. Tools such as pip natively handle virtual environments, automatically installing into it when one is active."
Which is another aspect of the very same problem. So their solution to ignoring they should seggregate functional development from bug fixing, that they should take API stability as an almost sacred cow is "reinventing" the "static linked environment"?
Try to install two disparaged tools based on the same shared environment and welcome to the fun of app A asking for 'foo 1.2.3' and app B needing 'foo 1.2.4', so you end up producing a virtual environment for each and every app you install. Good luck then with tracking security advisories for "foo" (and all the other dependencies of each installed app). Good luck with finding an upgrade path that will just fix known security issues without breaking functionality for any of your installed apps.
But, but, but... you should use the very bleedging edge -the developer of App A will say, without paying attention to the fact that you manage 2000 machines with 150 different main apps from different developers and dates, disregarding even that each of those developers will define "bleeding edge" as "whatever it happens to run in my development box, disregarding if it's really needed or it's stable or it will be supported by my dependecies' developers".
each of those developers will define "bleeding edge" as "whatever it happens to run in my development box, disregarding if it's really needed or it's stable or it will be supported by my dependecies' developers".
You're describing a development problem, not a deployment problem. Development requires standardization just like deployment does. You're model also seems to lack any type of testing or quality control procedures which will also put a stop to that non-sense.
Done properly, virtual environments allow you to do things properly, far more easily. Done in a circus, it can clearly make things far worse. Solution? Don't work in a circus and blame your tools.
The confusion of a staff member is measured by the length of his memos.
-- New York Times, Jan. 20, 1981
Autotools do not need a book (Score:5, Insightful)
... they should be replaced by something else.
Re: (Score:1, Troll)
Re: (Score:5, Interesting)
I often need to install software in an environment that's different from where it's going to be run, e.g. I install it on a file server, where the target directory is /export/apps/stow/, and then I use "stow" to put it in /export/apps, which clients mount as /usr/site, so they see "/usr/site/bin/", and are set up to look in /usr/site/lib for libraries, and so forth.
I don't know if this is instrinsic to newer build schemes or not, but my recent experience has been that "old-style" (autotools-based) packages
Re: (Score:4, Informative)
I've run into the same problem with cmake. I don't really have that problem with python tools as python's virtual environment tools [python.org] seem to handle things nicely. Tools such as pip [python.org] natively handle virtual environments, automatically installing into it when one is active.
Also, there are lots of nice wrappers [python.org] to work with python's tools, for developers, such as gogo [bitbucket.org].
Re:Autotools do not need a book (Score:3, Interesting)
"I don't really have that problem with python tools as python's virtual environment tools seem to handle things nicely. Tools such as pip natively handle virtual environments, automatically installing into it when one is active."
Which is another aspect of the very same problem. So their solution to ignoring they should seggregate functional development from bug fixing, that they should take API stability as an almost sacred cow is "reinventing" the "static linked environment"?
Try to install two disparaged tools based on the same shared environment and welcome to the fun of app A asking for 'foo 1.2.3' and app B needing 'foo 1.2.4', so you end up producing a virtual environment for each and every app you install. Good luck then with tracking security advisories for "foo" (and all the other dependencies of each installed app). Good luck with finding an upgrade path that will just fix known security issues without breaking functionality for any of your installed apps.
But, but, but... you should use the very bleedging edge -the developer of App A will say, without paying attention to the fact that you manage 2000 machines with 150 different main apps from different developers and dates, disregarding even that each of those developers will define "bleeding edge" as "whatever it happens to run in my development box, disregarding if it's really needed or it's stable or it will be supported by my dependecies' developers".
Ahhh, youngsters... now, you get off my lawn!
Re: (Score:0)
each of those developers will define "bleeding edge" as "whatever it happens to run in my development box, disregarding if it's really needed or it's stable or it will be supported by my dependecies' developers".
You're describing a development problem, not a deployment problem. Development requires standardization just like deployment does. You're model also seems to lack any type of testing or quality control procedures which will also put a stop to that non-sense.
Done properly, virtual environments allow you to do things properly, far more easily. Done in a circus, it can clearly make things far worse. Solution? Don't work in a circus and blame your tools.