5 ms·

The `cpan` command line utility automatically downloads and installs dependencies when you use it to install a module. It's the rough equivalent (and precursor

by mapgrep 15y ago

The `cpan` command line utility automatically downloads and installs dependencies when you use it to install a module. It's the rough equivalent (and precursor to) ruby's `gem`.

telemachos 15y ago
I very strongly recommend cpanminus (aka, cpanm)[1] over cpan now. It's zero configuration, lighter on memory use and much more straightforward for most uses. [1] https://github.com/miyagawa/cpanminus https://github.com/miyagawa/cpanminus
- pyre 15y ago
  I'd also recommend using perlbrew+cpanm instead of using cpanm to muck with the system-installed perl, sometimes this can cause breakage for core system components that run on perl (and are only tested against the system-installed version of perl + packages).
  - prodigal_erik 15y ago
    > cpanm to muck with the system-installed perl, sometimes this can cause breakage for core system components Yikes. This would be why I don't share root with anyone who thinks it's a good idea to smuggle stuff onto a box without going through the system package manager (which is rpm or dpkg or the like, not the cpan client or any other single-language ghetto).
    - pyre 15y ago
      Sorry. I meant that: - Installing stuff into system directories from through a second package management system (perl = cpan, ruby = gems, etc) is generally a bad idea (e.g. the apt-maintained perl libraries are not seen by cpan, so it will need to install those if there is a requirement for one of them in a cpan package you are installing). - Upgrading versions of Perl libraries that are used by system (outside of the official package management system) Perl scripts can cause unexpected results. This is why perlbrew is useful. It manages self-contained Perl installations that you can switch between in your particular environment. The only downside that I've seen is with system-installed scripts that use the "#!/usr/bin/env perl" method to specify which Perl to run. I haven't seen this, in particular with Perl scripts, but I ran into this with virtualenv + comix as a Python script with "#!/usr/bin/env python" for the shebang line (it blew up since my virtualenv didn't have py-gtk installed).
      - prodigal_erik 15y ago
        > manages self-contained Perl installations That's what a lot of languages resort to, but as the proverb goes, now you have two problems. We instead make OS packages out of library dependencies that didn't already have them, so we have a way to legitimately deploy them to production servers.

by mapgrep 15y ago

The `cpan` command line utility automatically downloads and installs dependencies when you use it to install a module. It's the rough equivalent (and precursor to) ruby's `gem`.

telemachos 15y ago

I very strongly recommend cpanminus (aka, cpanm)[1] over cpan now. It's zero configuration, lighter on memory use and much more straightforward for most uses. [1] https://github.com/miyagawa/cpanminus https://github.com/miyagawa/cpanminus

pyre 15y ago
I'd also recommend using perlbrew+cpanm instead of using cpanm to muck with the system-installed perl, sometimes this can cause breakage for core system components that run on perl (and are only tested against the system-installed version of perl + packages).
- prodigal_erik 15y ago
  > cpanm to muck with the system-installed perl, sometimes this can cause breakage for core system components Yikes. This would be why I don't share root with anyone who thinks it's a good idea to smuggle stuff onto a box without going through the system package manager (which is rpm or dpkg or the like, not the cpan client or any other single-language ghetto).
  - pyre 15y ago
    Sorry. I meant that: - Installing stuff into system directories from through a second package management system (perl = cpan, ruby = gems, etc) is generally a bad idea (e.g. the apt-maintained perl libraries are not seen by cpan, so it will need to install those if there is a requirement for one of them in a cpan package you are installing). - Upgrading versions of Perl libraries that are used by system (outside of the official package management system) Perl scripts can cause unexpected results. This is why perlbrew is useful. It manages self-contained Perl installations that you can switch between in your particular environment. The only downside that I've seen is with system-installed scripts that use the "#!/usr/bin/env perl" method to specify which Perl to run. I haven't seen this, in particular with Perl scripts, but I ran into this with virtualenv + comix as a Python script with "#!/usr/bin/env python" for the shebang line (it blew up since my virtualenv didn't have py-gtk installed).
    - prodigal_erik 15y ago
      > manages self-contained Perl installations That's what a lot of languages resort to, but as the proverb goes, now you have two problems. We instead make OS packages out of library dependencies that didn't already have them, so we have a way to legitimately deploy them to production servers.