5 ms·
What does the packaging system for perl look like these days? Does `cpan install` somewhat work? One of the reasons I have never gone back to Perl after moving
by quadrifoliate 6y ago
What does the packaging system for perl look like these days? Does `cpan install` somewhat work?
One of the reasons I have never gone back to Perl after moving to Python in the early 2000s is that the packaging system was horrific. Even Python's weird mix of system packaging and pip mostly just works, and the story has gotten a lot better with virtualenvs, pip, and such.
Meanwhile I have rarely successfully installled anything with CPAN, it always seems to fail out with some odd error in the middle of building something. Experiences like this make the activation energy required for me to do any fun side projects using Perl instead of Python.
Are my observations atypical? Is there a better way to use and install third-party Perl packages that I don't grok?
- perlgeek 6y agoThese days I tend to compile my own perl using perlbrew, then run $ perlbrew install-cpanm $ cpanm install What::Ever This works nearly always, except when header files or C libraries are missing on the system (like you need libpq-dev on Debian/Ubuntu to install DGD::Pg, the postgresql database connector). With the system perl, local::lib also works, but it's a bit fiddly to set up initially.
- petre 6y agoCpanm this, cpanm that. It works. There's also perlbrew and plenv. And cpanfiles. Stuff that requires C libs is sometimes more tricky.
- folmar 6y agoIt is atypical. Cpan install just works and has been like that at least 15 last years. Also major package managers have automated converters which are mature, so one-step install and convert is also a thing. Python's pip+virtualenv is often much worse, so many of the packages need `wheel` but don't depend on it and failed builds are treated as successful, so it's not as smooth as could be, but much is improved since Python 3.5+.