I would like to know the difference between the 2 methods in terms of how dependencies are handled, ease of use and configurability.
If you install from source, you lose ease of use (you have to follow a procedure yourself instead of clicking a button to install) and you have to resolve your own dependencies in many cases, whereas a package manager would do this for you in most cases. However, you gain a lot of configurability (pick and choose versions, where to install, even modify source).
Also, there's a lot of stuff out there that you can only get if you install from source, because packages haven't been made (or kept up to date), especially if you use one of the less popular package managers.
What about building software from source with the help of a package manager? Think gentoo's emerge. You see, the two choices you present are not necessarily mutually exclusive alternatives.
Related
Recently I started to use a private npm packages for backend.
They stored on our private packages server (an npm repository I deployed among application components.
And while I mostly like how it all works and happens, but there is a gotcha.
Imagine a packages like:
#example/logging, #example/utilities, #example/validation, #example/database, #example/security - low-level packages. And many of these low-level packages depends on #selfcad/logging package.
#example/updates-queue, #example/subscriptions, #example/auth-tools, #example/cloud-functions and #example/backend-core packages are representing high-level abstractions and components. Each of high-level packages depending on few or sometimes all of low-level packages.
Some of these packages are referenced in cloud functions via #example/cloud-functions package, especially low-level packages. Other used directly in a cloud functions.
Plus there is a backend component where most of packages are used directly.
So, true headache starts, when a change must be made e. g. in the low-level package like #example/logging or #example/validation.
And what is the most easier way to spread the update or fix to widely referenced lower package? With nested dependencies.
Like so: a package, e. g. #example/validation referenced directly and indirectly, like #example/configuration uses #example/validation, #example/database uses #example/validation and I updated #example/validation internals. How to spread such update across packages?
Maybe you should have a look to Yarn Workspaces. This is a useful feature of yarn to link dependent packages each others using a mono repo. This feature also includes auto-discovery/auto-linking.
I built ZeroMQ and Sodium from source and have them installed properly on my development machine, which is just a Pi2. I have one other machine that I want to make sure these gets installed to properly. Is there a proper way to do this other than just copy .a and .so files around?
So, there are different ways of handling this particular issue.
If you're installing all your built-from-source packages into a dedicated tree (maybe /usr/local, or /opt/mypackages) then simply copying files around is a fine solution, using something like rsync. Particularly since you only have two machines, anything more complicated may not be worth the effort.
If you're trying to install ZeroMQ and Sodium along side system-managed files (in, e.g., /usr/lib and /usr/bin)...don't do that. That is, don't try to mix "things installed by packages" with "things installed from source", because that way lies sadness and doom.
That said, a more manageable way of distributing these files would be to build custom packages and then setting up a local apt repository, so that you can just apt install the packages on your systems. There are various guides out there for doing this if you want to go down this route. It's a good skill to have in general, especially if you ever want to share your tools with someone else (because it makes it easy for them to install any necessary dependencies).
Practically speaking, are these essentially synonymous? Or is there something I'm missing? I've use Composer (PHP), CocoaPods (Objective-C), and Bundler (Rails). I believe they describe themselves as dependency managers but can they also be consider as package mangers?
I'd say yes. Given that the javascript community calls their version of those tools (NPM and bower) "package managers", I think that the development community has essentially synonymized those terms.
EDIT I'm going to backtrack a bit. In general, I think the term package manager has to do with the delivery and installation of third party code. That said, npm is correctly named the node package manager. As I see it, a dependency manager is a different thing. It's an runtime orchestration tool. For example, there are dependency managers that simply run in the browser to load asset files in the proper order (think requireJS, browserify, cartero, etc... - or think a Dependency Injection container in say Symfony2 or Laravel) but you wouldn't call those package managers. A package manager would be something like Debian's dpkg or the node community's bower, which actually downloads third party libraries for you (that aren't currently in your software suite). Now, I think the burred lines come in when package managers decided to be smart enough to resolve version numbers for us. Because tools like npm make sure that each piece of software we declare has all of the proper versions of it's dependencies (by downloading a chain of dependencies for us), we want to call it a dependency manager. But I think it's more proper to say that it's a package manager that happens to do version resolution. It's really more of a delivery mechanism than a runtime tool, though.
All that to say, I'd like to hear what others have to say about this.
No, they are not synonyms. Look At that answer for their difference
https://stackoverflow.com/a/27290095/4016254
Sometimes a project can be organized either as a single package or as several packages. When one is in such a situation, how should one decide which option is better?
There are some immediate drawbacks of distributing a project over multiple packages:
the build process is more complicated than just cabal build
releases and version numbers have to be coordinated
users have to install and depend on multiple packages
API documentation is scattered on hackage
But there are also potential benefits for users that would only depend on a subset of the packages:
they don't have to download, compile, link, install, trust and license code in packages they don't need
they don't have to download, ..., and license dependencies of packages they don't need
they can discover packages more easily if their name and metadata is specific to the individual package, not the whole project
And there are some benefits even if users end up depending on all packages:
different packages can have different maintainers and/or release schedules
I think the decision should be based on whether you think that there are users that can actually realize the potential benefits. So I would say that the decision depends mostly on the answers to the following questions:
Is there a part of the project that changes much more often than the other parts?
Is there a part of the project that is more or less trusted than the other parts?
(for example, a core package and a contrib package)
Is there a part of the project that has many additional dependencies but is not needed by all users?
(for example, an interface to another project)
Is there a part of the project that can be reused independently of the purpose of the overall project?
(for example, a combinator library used in the main project)
Is there a part of the project that forces users to use a specific license (directly or via dependencies) but is not needed by all users?
Finally, with cabal there is a middle ground between "one package" and "many packages", because one cabal package can contain both one library and any number of executables, test-suites and benchmarks. This covers one important reason that would otherwise lead to split packages: Users should not have to depend on the testing libraries just to use the package.
I am looking for a good way to install an application I developed with all its dependencies in a fancy way. Currently I have a big make file that downloads, unpacks, compiles and installs all dependencies. This however is a little tedious, since there are quite a few dependencies and the make file is getting larger and larger which eventually will be hard to maintain. Therefore I am looking for a packaging tool with the following features:
It should be a light weight package manager which is very easy to install (or even installs itself and afterwards all my dependencies)
The destination of the installed binaries, libraries etc. should be customizable
Each installation process of a dependency should be easy configurable
It should be possible to include self written scripts that get executed at a specific point during the installation process (in order to manipulate make files, flags etc)
No admin rights should be necessary since all clients that install my application will not have admin rights and are not able to use an already installed package manager
I do not know if this kind of software exists. I myself don't have much of experience with packaging tools.
Thx in advance for any link, hint, suggestion!
opkg is something thats based on ipkg (now defunct) and originally dpkg. Its used in embedded systems. Light weight for sure.
ports from crux linux (www.crux.nu)?
A quick search returns InstallJammer. I would propose make debs and rpms and tarballs and stick with standard installation process (root privileges and such)m but if you can't do that, then, well, you can't.
I'm sure you know how suspicious it would look for the user.