RejectedSoftware Forums

On Thu, 19 Sep 2013 21:04:18 GMT, Dicebot wrote:

It is not a package manager in normal sense (those can't and shouldn't be language specific). It is just a development tool to control project dependencies and inter-operation, on a source code level. Its main goal, as I see it, is to provide you easy and convenient way to build certain library / program. Installation of built stuff is not its business (it can provide helpers for real OS tools though)

I just don't agree with you.

/Jacob Carlborg

On Fri, 20 Sep 2013 07:43:55 GMT, Jacob Carlborg wrote:

1. For that to work they need to be "installed". That is, compiled and put in some directory, somewhere. That's what I've been talking about all along. I have never said they need t be put in some standard search path, i.e. /usr/lib. Although it is convenient to put applications in PATH, some way or another.

They can be compiled in the very same git clone directory. As I have said, convenient syntax sugar on top of git clones.

1. That doesn't work for applications

Works at least in Linux:

PATH=$PATH:/path/to/my/clone/dir dub build

No need to pollute normal namespace, clean and hygienic.

A problem with some OS package managers is that they are so religious so they won't even add a package if it's not following the appropriate licensing. Some package managers won't add DMD due to this.

Then those distros won't have that software. It is their chose and we shouldn't interfere. If users won't agree with that restriction, they will change the distro. Why force software they don't want?

Actually, I have heard of quite mature generic package manager implementations for both Mac and Win, those just don't get any traction / recognition.

As long it's not installed by default it cannot be relied on.

dub is not installed by default too

On Fri, 20 Sep 2013 22:28:30 +0200, Jacob Carlborg wrote:

On 2013-09-20 17:05, Dicebot wrote:

On Fri, 20 Sep 2013 07:43:55 GMT, Jacob Carlborg wrote:

1. For that to work they need to be "installed". That is, compiled and put in some directory, somewhere. That's what I've been talking about all along. I have never said they need t be put in some standard search path, i.e. /usr/lib. Although it is convenient to put applications in PATH, some way or another.

They can be compiled in the very same git clone directory. As I have said, convenient syntax sugar on top of git clones.

1. That doesn't work for applications

Works at least in Linux:

PATH=$PATH:/path/to/my/clone/dir dub build

No need to pollute normal namespace, clean and hygienic.

That's what I've been saying all along and you're been complaining that
it will break that world and is the most horrible thing one can do.

No. You were proposing to change PATH user-wide, i.e. "install". My example augments PATH temporary for one single build command. Outside of dub build process everything remains untouched. That is very important difference.

Then those distros won't have that software. It is their chose and we shouldn't interfere. If users won't agree with that restriction, they will change the distro. Why force software they don't want?

No one if forcing anything to be installed. Do you honestly believe that
a user would switch distro just because it's missing a package?

Depends. If it is a single important package he should create it himself. If it is a regular case and interferes the user needs - yes, of course. Package manager and packaging politics, if anything, are most important things to check when choosing the distro.