applications we wrote run on Solaris exclusively. all the modules and plugins are installed out of solaris packages. i.e we have to wait for the unix team build and install it for us first. aparently they are busy as hell and the difficulities of installing Perl modules usually make things worst. thus a request may take weeks to finish.
for the pure Perl module, this is not much issue. we just drop it to our common lib directory.
today i need Text::CSV_XS to parse lots of CSV files. but alas.. it is XS.
i am glad that Perl usage at my workplace is going up. but this just slows thing down. another example, the mod_perl request's been in the queue for two weeks .. :-(
Can you get a dedicated perl user that owns
Not having access to Text::CSV_XS is ridiculous. Having to wait two weeks for it is ridiculous. Not being able to put it in a development area yourself to work with would be beyond ridiculous, but hopefully you can at least install the module somewhere you have write access to and set the PERL5LIB environment variable until your admins catch up with reality.
Developers ought to have complete control over the development platform. This is the reason. If administrators are required to "protect" something, then that something should be production, and your organization would be well-served by formalizing the boundaries between development and production, and letting the developers have control over the development server/instance.
Re:Build your own
jhorwitz on 2007-04-02T19:35:59
Developers ought to have complete control over the development platform. This is the reason. If administrators are required to "protect" something, then that something should be production, and your organization would be well-served by formalizing the boundaries between development and production, and letting the developers have control over the development server/instance.I both agree and disagree with you here. Most developers do not know how to properly administer a server or even their own workstation. I don't care if they use Linux at home. Professional sysadmins have the experience in this department, and it's their job to maintain the infrastructure. And yes, having been a sysadmin for almost 12 years, I'm biased.
:) In my experience, it's critical that developers have a consistent environment to work with. As an example, an improperly configured development server could very easily cause software to behave differently than on a properly maintained staging or production platform, or even other development boxes. Who's to blame when the software fails in production? And what happens if the security is compromised on the development server? You should at least have some minimal controls in place.
Now, that said, I agree with you that developers should be in control of their own application stack on the development servers. I agree that it is completely unacceptable that anyone has to wait two weeks for a Perl module, and that developers should have their own installations to work with. But the underlying operating system, no. Unless they're kernel developers, of course.
;-) Re:Build your own
jdavidb on 2007-04-02T23:56:04
I'll also both agree and disagree with you.
:) Developers should have the support of admins who do maintain the OS, etc. There should be some standard configuration the admins can restore, and the developers ought to be able to request needed changes (for some apps that might be the OS level, for others it might be as simple as a Perl module or even a config file) and receive those in a timely manner, and all of it ought to be well-controlled and not put into production until it is well-documented and reproducible. Some of the particulars as to who makes the change don't matter as much as long as it is both timely and well-controlled, and some of the particulars as to what should be under admin purview and what should be under developer purview will vary from situation to situation. Re:Build your own
Qiang on 2007-04-02T19:56:12
on the development server, i can install modules to my home directory and use it from there. however, i need to make sure that the module that i am using under dev environment will be available to me on production.in the linked journal, you are using CPAN for moudle installation. do you do that in production environment? if not, do you build pkg for each module for every version of Perl? do you reuse some of the Perl modules built against older Perl?
also, you mention the update of symbolic links from
/usr/local/bin/to/usr/local/perl??/bin/. such asperldoc,splain. my question is why aren't those links in/usr/local/perl???/bin/? how do you cope with those links if you have more than two Perl installed? I will do some more research on this and hopefully have a better solution for our enviroment.Re:Build your own
jdavidb on 2007-04-03T00:06:35
in the linked journal, you are using CPAN for moudle installation. do you do that in production environment? if not, do you build pkg for each module for every version of Perl? do you reuse some of the Perl modules built against older Perl?Sadly, when it comes to Perl, the lines between development and production are badly blurred in my organization. Happily, it tends to affect only me.
:) I have gone the route of building Solaris packages for Perl modules. I would never do this again, if I could help it. I believe the ideal situation would be a production installation of Perl managed by CPAN shell and never touched to add or upgrade a module until all code had run regression tests against a development instance that had been so updated first, to test. Then, simultaneously, a development instance where modules are updated all the time, as long as they pass their own tests, to smoke out potential problems as soon as possible in development. (With more developers, you probably wouldn't want the dev instance to be so "bleeding edge," but more intermediate between the two extremes.) One approach to production might be to build your own local CPAN repository that contains only tested and approved versions of modules and then have the production server(s) update from that repository only. Another approach might be to distribute a single custom Perl package (doing
/usr/local/perl/5.8.8 makes it easy/easier) as a tar.gz or as an OS package; you release a new update to the package when you need new modules added or a newer version. I'd rather do that than separate OS packages for each module. If there's only one OS package to deal with, then your environment is far more predictable. :) also, you mention the update of symbolic links from/usr/local/bin/ to /usr/local/perl??/bin/. such as perldoc, splain. my question is why aren't those links in /usr/local/perl???/bin/ ? I should mention that now instead of
/usr/local/perl588 I recommend an installation location of /usr/local/perl/5.8.8 . This puts all (or most) installations of perl under a common directory which can be much handier (and keeps /usr/local cleaner). Under my recommendations,
/usr/local/bin will contain symbolic links to links to the real version of each utility in /usr/local/perl/x.x.x/bin. I'm not sure I understand your question as those links cannot be in the other location because the real versions of the utilities are there. ??? Under this layout, developers tie their programs directly to something like #!/usr/local/bin/perl5.8.8 on the first line of the program; then, when new versions of perl are installed, each program can continued to be tied to the old version until tested against the new, at which time the #! line can be changed to #!/usr/local/bin/perl5.8.9 . The two perls will be completely independent; each will have its own independent set of modules, etc. Nothing will break for 5.8.8 programs while you experiment with 5.8.9 when it comes out. Another approach would be to forget the links in
/usr/local/bin entirely and just change your PATH to include /usr/local/perl/x.x.x/bin and set the top line of your programs to be #!/usr/local/perl/x.x.x/bin/perlx.x.x .
