Re: Bringing CPAN,Gems, PIP, PyPi, etc. under APT package management

[songbird <songbird@anthive.com>]

Dan Ritter wrote:
...
> There are good reasons for doing this on a local basis.

  sure, and nothing prevents that from being accomplished.
it isn't like the tools would go away.


> For example, let's say you have an organization that develops
> a software service and sells access to it. When an engineer asks 
> for a particular library, it turns out to be a really good idea
> to immediately turn it into a Debian package so that you can
> keep the same version all the way through the chain to
> production.
>
> Many of the language-specific tools have a tendency to
> automatically acquire the latest version of a library or module
> every time they are invoked, or to spit errors if they can't
> pull down the version that they were asked to get. That's rather
> troublesome.

  if you are that exposed it sounds kinda risky as a 
business practice (i.e. not one i would engage in).


> Having a local apt repository with all the versions of a
> library that you've actually used, so you can re-deploy an old
> one exactly the way it was or install a fixed version across
> a set of machines is very, very useful.

  if you are dependent upon code it would sound to me to
be rather foolish if you did not have some kind of version
control and release processes where you tracked your code
and the libraries/dependencies.


> As long as the tools exist to take a language's
> libraries/modules/packages and turn them into a Debian package
> exist, all the rest of the infrastructure is already in place.
> There's no real need to try to pre-package all of CPAN, CRAN, 
> CTAN, Ruby Gems, pypi...  

  if you are a big enough company that can afford to have
people doing that and maintaining them, but to me it seems
more reasonable to just do version control processes and
track your releases.


  songbird