9. The awesomeness
perl is very backward compatible
Ideal for production
keep upgrading perl is generally OK
don’t necessarily have to upgrade
cpan modules following a perl
upgrade.
10. The huh
CPAN modules are not necessarily
backward compatible.
XS modules might need to be
recompiled with new perl
Upgrading modules might not be
avoidable.
11. The hmm
The current CPAN architecture sort of
encourages upgrading
The default is to install the
latest version of modules.
Upgrading CPAN modules isn’t
necessarily smooth.
12. The err
Errors happens at runtime
XS errors happens at install /
compile time and it is ^%@&* to
solve.
13. Worst of all
Have to upgrade perl before doing all
that.
an all-in-ish move
14. Worst of all
Dirty state
100 CPAN modules are updated
1 failed
Can’t easily revert
17. Practicals
Module authors have to correctly
specify module dependencies.
Module users have to run tests in
order to reveal runtime errors.
assuming there are sufficient
numbers of tests
30. Usage
perlbrew lib list
perlbrew lib create nobita
perlbrew lib create perl-5.14.2@nobita
perlbrew use perl-5.14.2@nobita
perlbrew lib delete perl-5.12.3@nobita
31. cd ~/src/App-Awesome
perlbrew use perl-5.10.1@app-awesome
perlbrew use perl-5.14.2@app-awesome
cd ~/src/Module-Awesome
perlbrew use perl-5.10.1@nobita
perlbrew use perl-5.14.1@nobita
perlbrew use perl-5.14.2@nobita
40. Benefits
`sudo cpan` is no more
easier-to-clean perl environments
Nuke the whole thing to clean the
mess
No old @INC
41. Benefits
per-app isolated perl environments
setup.
avoid, in advance, any possible
incompatible issues with other
apps.
know your libs
42. Benefits
avoid lib conflicts with what you had
install older versions of modules
without worries to break other app
code.
cpanm http://URL.TO/Mo-0.1.tar.gz
App::pmuninstall
43. Rationale
Don’t mess up vendor perl too much.
Learn new stuffs in the dev version
of perl.
keep up with the fashion
49. Thoughts
rvm
bash programming master-piece
developer-friendly experiences
production uses
50. Further Thoughts
Deprecate switch/use to external perl
Improve multi-user scenario
More related tool to help developer
identify module upgrade failure, and
revert to a good state.
51. Further Thoughts
Good + Simple toolkit
Keep new-comers by not frustrating
them
Grow the community
I started writing perlbrew in Feburary, this year, and it have became a lovely tool for hackers.\n
I started writing perlbrew in Feburary, this year, and it have became a lovely tool for hackers.\n
\n
\n
Besides vendor perl, when one manually (or done with some port system) build perl, it’s usually /usr/local or /opt/local. I build it in with $HOME/local because I don’t like to do type `sudo`.\n\nI ended up using all of above and upgrading perl become such a dangerous move. Especially when you need to re-compile several binary / XS modules.\n\nThe problem is: you simply forgot what to re-complie!\n
Besides vendor perl, when one manually (or done with some port system) build perl, it’s usually /usr/local or /opt/local. I build it in with $HOME/local because I don’t like to do type `sudo`.\n\nI ended up using all of above and upgrading perl become such a dangerous move. Especially when you need to re-compile several binary / XS modules.\n\nThe problem is: you simply forgot what to re-complie!\n
The perl interpreter is like the most backward program ever. It deprecates no inputs, and produce very consistent result.\n
\n
Modules tend to be re-write with XS / C for speed improvement. Sometimes the binary is’nt compatible to the old versions. IMHO this basically conflict with site_lib-preserving upgrade policy.\n\nIt does’n always happened, but when it happens, you see errors at runtime. Which makes you anxious: Is there anymore of these sort of errors?\n\n
Modules tend to be re-write with XS / C for speed improvement. Sometimes the binary is’nt compatible to the old versions. IMHO this basically conflict with site_lib-preserving upgrade policy.\n\nIt does’n always happened, but when it happens, you see errors at runtime. Which makes you anxious: Is there anymore of these sort of errors?\n\n
\n
\n
\n
\n
Modules tend to be re-write with XS / C for speed improvement. Sometimes the binary is’nt compatible to the old versions. IMHO this basically conflict with site_lib-preserving upgrade policy.\n\nIt does’n always happened, but when it happens, you see errors at runtime. Which makes you anxious: Is there anymore of these sort of errors?\n\n
\n
It’s basically designed for single-user, developing purposes.\n\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
If your CPAN installation somehow get messed up too much, you can always nuke the whole thing to star over.\n\nUpgrading /usr/local/bin/perl to a new version will put keep old site_lib dirs alone with the new site_lib dirs in the @INC. This causes problems particularly on binary modules.\n
\n
\n
\n
TEST. OF COURSE. Perl Community really loves to talk about testing. And they hate it sometimes.Just have a more precise idea how your piece of software work with different versions of perl.\n
perl interpreter itself must be configured with different compiling arguments to fit certain purses.\n\nQ: perl 5.12 / 5.13 features performance improvements. How much does that benefit my software?\n\n
\n
Many ideas of perlbrew comes from cpanm. (Distributing / Embedding modules... etc)\nrvm is a comprehensive implementation to build multiple rubies. It’s a big load of bash functions with bash scripts. But it works amazingly well.\n
easy to distribute - just one download !\nA pure-perl program pretty much runs anywhere just fine.\n
\n
These tools I wrote / encountered all feature just one simple job and only that.\n\nThey do not have many sub-commands or arguments so there are very easy to learn.\nNor are they big packages that takes longer to install or to load and run.\n
These tools I wrote / encountered all feature just one simple job and only that.\n\nThey do not have many sub-commands or arguments so there are very easy to learn.\nNor are they big packages that takes longer to install or to load and run.\n
