[gens]

Totally different ? Are you sure about that ?

>.. does absolutely nothing to help build your code ..

I don't know much about cargo nor rust. How does it help build your code ? edit: nvm, i found how [0]

>.. manage dependency versions ..

All package managers do. Granted not implicitly when building your source, as you have to install them yourself. Good libraries can have multiple versions installed at the same time (i won't go into nix and such).

>.. control how dependencies are built ..

Most (of the used) programming languages don't need to build dependent libraries, they load them dynamically.

Note that I don't differentiate between code in headers, code in libraries, or even code in other programs that the specific program would communicate with via some IPC. (side note: i have grown fond of single header libraries, for their simplicity)

Also to quote the rust docs "Rust has two distinct terms that relate to the module system: ‘crate’ and ‘module’. A crate is synonymous with a ‘library’ or ‘package’ in other languages." Not 100% what i was saying, but it does hint on how similar cargo is to a "normal" package manager.

It seems that everyone wants to build in a package manager these days. Rust, racket, haskell, python... What is wrong with copy-ing code directly ? Do we need these ? It just reminds me of leftpad.

[0] http://doc.crates.io/index.html

[Rusky]

Everyone wants to build a package manager these days because OS-wide package managers don't provide the same feature set that language-specific package managers do.

[Annatar]

Which feature set would that be?

[beagle3]

At the very least (npm, conda) multiple independent environments, allowing conflicting versions of a library to exist simultaneously in different environments. If the language allows it, even in the same environment.

To get that from apt/yum/pacman you need chroots, containers or virtualization.

[Annatar]

At the very least (npm, conda) multiple independent environments, allowing conflicting versions of a library to exist simultaneously in different environments.

One should never, ever bypass the operating system's software management subsystem, because then, one needs a hack like Docker, since the OS will have no notion of the software installed, and a system specifically invented and designed for managing said software won't be able to manage it. I could author a book on just how bad of an idea using a packaging system proprietary to some language or application is. By utilizing a packaging system outside of the operating system's packaging, anyone doing so undermines operational repeatability (see capability maturity model level 2 and higher).

allowing conflicting versions of a library to exist simultaneously in different environments.

That's another very bad thing: it's a workaround for lack of thinking about backwards compatibility, and designing a single library with multiple versions of the API, and, and, and... I happen to work on an application which utilizes 300 such environments, and it's a nightmare.

Finally, by using a packaging system proprietary to a language, anyone doing so is now forcing everyone else who wants to use said software to wrestle with multiple packaging systems; and if every developer thought that way, the end consumer would have to wrestle with all of them. I don't think I need to point out just how irresponsible, not to mention inconsiderate that is towards users. Users of the application, not developers should come first, and only then everything else. In this day and age of automated builds, it is trivial to set up automatic generation of operating system packages for various systems. Trivial, and developers must take responsibility for that, instead of putting the onus on the consumer of the software.

[beagle3]

> One should never, ever bypass the operating system's software management subsystem,

Neither conda nor npm does something like that. They set up a localized environment, insulated from the host os installed software as far as packages they manage are concerned.

> By utilizing a packaging system outside of the operating system's packaging, anyone doing so undermines operational repeatability (see capability maturity model level 2 and higher).

No they don't. I'm not sure about NPM, but conda documents exactly what packages are installed inside it, generates a specification file you can use on another install to recreate the same environment, and insulates the inside install from changes in the underlying OS.

> That's another very bad thing: it's a workaround for lack of thinking about backwards compatibility, and designing a single library with multiple versions of the API, and, and, and... I happen to work on an application which utilizes 300 such environments, and it's a nightmare.

Feel sorry for you. But I have to maintain two projects, one requires an older version of the library, one requires the newer. There is no way to achieve this with "apt-get" or "yum". Conda lets me develop both on the same machine in a repeatable way. And it's way better than any other solution I'm aware of.

> I need to point out just how irresponsible, not to mention inconsiderate that is towards users. Users of the application, not developers should come first, and only then everything else. In this day and age of automated builds, it is trivial to set up automatic generation of operating system packages for various systems. Trivial, and developers must take responsibility for that, instead of putting the onus on the consumer of the software.

What?

There are many packaging systems for Linux/BSD/Unix I use often (apt/deb, yum/dnf/rpm, pacman, ports, brew, cygwin), even more repositories (ubuntu, debian, ...) and there is absolutely zero chance that I can rely on dependencies to be provided by the OS package manager - they don't update at the same rate, and sometimes not in a compatible way (e.g. PIL vs. Pillow migration for Python; ffmpeg vs libav).

Conda, however, makes that a simple "conda install" away, once you have conda installed. And it also works on Windows - which has no canonical package manager (chocolatey is the closest, but it is still very far).

What you are suggestion is useless in my situation, and for at least 95% of the developers and deployment situations I'm familiar with. If it works for you, then ... good for you. But you're pretty unique.

[Annatar]

Neither conda nor npm does something like that. They set up a localized environment, insulated from the host os installed software as far as packages they manage are concerned.

That is exactly what I mean by bypassing the operating system's software management subsystem. No software or configuration should ever be installed by anything other than the operating system's software management subsystem. It is the responsibility of the developer (you or anyone else doing so) to convert content pulled in by npm or anything that is not an OS package into one, but the best solution is to fix it upstream by abolishing these parallel software management subsystems, and automatically generating native OS packages for the software through continuous integration build processes.

Not doing so puts the onus on the consumer of the software, and to wit, the purpose of software is to make it easier, not harder or more time consuming, to do something. Imagine forcing the system administrator to have to replicate your development environment, through any mechanism, just to be able to run your application and all her dependencies, when she or he could have just plugged in OS packages of your software into the OS provisioning repository.

Feel sorry for you. But I have to maintain two projects, one requires an older version of the library, one requires the newer. There is no way to achieve this with "apt-get" or "yum".

Actually, yes there is: make the library interfaces versioned, and fuse them into one library for all versions of the consuming software. This is, post action, considerably more work, but that is what developing software is all about. The idea of versioned interfaces is not new, and originates on UNIX. Since the initial topic of discussion is building and linking libraries in C, the link editor can consume linker map files, which define the library's semantics based on the version of the interface, and will encode this information into the executable and linking format header of the binary. The encoded information will be consumed by the run time linker in order to present the correct version of the interface to the consuming application. Same principle applies to any software in any programming language.

There are many packaging systems for Linux/BSD/Unix I use often (apt/deb, yum/dnf/rpm, pacman, ports, brew, cygwin), even more repositories (ubuntu, debian, ...) and there is absolutely zero chance that I can rely on dependencies to be provided by the OS package manager - they don't update at the same rate, and sometimes not in a compatible way (e.g. PIL vs. Pillow migration for Python; ffmpeg vs libav).

Then the developer must provide the additional dependencies as OS packages, and can do so without interfering with the OS vendor by adhering to the System V / Linux Standards Base - Filesystem Hierarchy Standard: by delivering the payload in /opt[/namespace], the configuration in /etc/opt[/namespace], and coding the application to use data from /var/opt[/namespace]. The fathers of UNIX considered this, and provided specifications to address it accordingly.

http://refspecs.linuxfoundation.org/fhs.shtml

What you are suggestion is useless in my situation, and for at least 95% of the developers and deployment situations I'm familiar with.

As you can probably imagine, I disagree vehemently with your assertion, and it is my hope that through this dialog, I've managed to illustrate the reasons because of which that is so, as well as provided practical solutions to the problem at hand.

If it works for you, then ... good for you. But you're pretty unique.

You mean, I am unique in wishing to deliver software to the highest standards of quality enabled by our current technology? Having started as a system administrator, being a developer, I can completely understand the gargantuan amounts of work system administrators face trying to make developers' work repeatable, essentially being forced to complete developers' work for them. And that is simply not just, nor is it right. We as developers should do that.

Empathy is a core engineering value:

https://www.listbox.com/member/archive/182179/2013/05/sort/t...

respect your users and empathize with them. If you don't quite know how to solve the problem, ask system administrators to help you produce higher quality software, or even better, learn system administration yourself, just don't punt on the problem because you perceive it as too much work.