Do you use debian packaged libraries to develop new apps ?

[seedhe]

I have been using Debian for years, but these days I was thinking about if I should try to use the libraries provided by debian when I am working in a new project.

For example, if I am going to work in a Rails app I only have to install ruby-rails or in case of django python3-django.

Debian comes with lots of libraries for many languages ( like libghc.* for Haskell or lib.*-perl for Perl). Is a good idea to use them ? or is always better to use tools like rvm or virtualenv.



Note: I already know that using debian packages usually are not the current version of those libraries.

[stevepusser]

I have been using Debian for years, but these days I was thinking about if I should try to use the libraries provided by debian when I am working in a new project.

For example, if I am going to work in a Rails app I only have to install ruby-rails or in case of django python3-django.

Debian comes with lots of libraries for many languages ( like libghc.* for Haskell or lib.*-perl for Perl). Is a good idea to use them ? or is always better to use tools like rvm or virtualenv.



Note: I already know that using debian packages usually are not the current version of those libraries.

If you use Debian libraries, at least you'll know your application will be compatible with Debian.

[millpond]

I have been using Debian for years, but these days I was thinking about if I should try to use the libraries provided by debian when I am working in a new project.

For example, if I am going to work in a Rails app I only have to install ruby-rails or in case of django python3-django.

Debian comes with lots of libraries for many languages ( like libghc.* for Haskell or lib.*-perl for Perl). Is a good idea to use them ? or is always better to use tools like rvm or virtualenv.

--------------------------------------


One of the main reasons i came back to Linux was the problems MingW was giving me in compiling script languages. And a PITA to find ports of many libs.

You will save ALOT of installation time and aggrivation by using Testing/SID :
This is perl 5, version 28, subversion 1 (v5.28.1)
Python 2.7.15+
Python 3.7.2
ruby 2.5.3p105 (2018-10-18 revision 65156)

Perl: Apt should install its packages into *system perl* and will call them first. Anything installed from CPAN will be in *site perl* which will be called if not found, in system->site order. You can also symlink older installs of site dirs into the perl INC path. May have to use the 'use 5.xxx.xxx ' directive for that , though.

Python seems to be fine. I have noted that it will happily note when installing a module whther any of its dependencies are already installed, and from what I have seen the Debian repo has an enormous amount available (I have installed 95%).

Ruby I have not tested yet, but from my experience with it, Debian is a gift from gawd considering its utterly chaotic default package versioning. Hells bells, its archive has about a million files, but only around 40-50k packages. Some packages have around 50 versions! Stick with Debian for Rails, assuming you are using the latest version, and want to avoid the multiple versioning system it has.

I have seen Ruby break on a dist-upgrade, so you may well want to stay with a rolling testing/SID, though this may be rough on anyone new to Debian. Perl and Python appear more rugged, but strongly advise NOT to upgrade their *core* packages outside of the Debian repo. Historically, at least Perl/Python were(are?) used by key boot and startup scripts. If you must run different core versions, install them to /opt and keep them out of your path.