RejectedSoftware Forums

On 2013-09-15 12:43, Sönke Ludwig wrote:

Finally got NNTP working :)

Since the default build type is "debug" that should definitely be included. Executing the equivalent of "dub build" and "dub build --build=release" for each newly installed package would basically do this. Once a better build system is in place that would be an option.

As far as I know, the only thing the -debug flag does is enable the
"debug" statements. Most of the use cases I have seen prints some
information to the console. I would really hate to have that by default.
That's only useful when one needs to debug a third party package which
doesn't behave as it's supposed to. I think that by default we should
assume that they do behave as they're supposed to.

What is useful is to have debug symbols, that is the -g or -gc flag.

Difficult call with the branches and starting tracking just after the first version tag. It would be a lot cleaner, but on the other hand there are a lot of packages now where the author doesn't feel comfortable yet to start tagging versions (even if that is an unjustified feeling). IF we end up with half the number of packages by forcing version tags, that would arguably be worse overall for the system.

Hmm.. maybe a little psychological trick can help here: non-tagged packages could always occur after tagged packages in the list (assuming that they are in a pre-release state) or get some kind of visual "beta" tag, so that the author is kindly forced to start making tagged versions to get more people to use their packages.

A "beta" flag or similar might be a good idea. Possibly a button to
show/hide these beta packages. The idea of sorting non-tagged package
last is also good.

We should come up with a better name than "beta" since according to the
semantic versioning scheme you're allowed to have versions like
"0.2.0-beta", "0.2.0-alpha" and "0.2.0-rc1".

True, but I also often have the situation with vibe.d that a quick fix is needed for someone and making a release would be too much effort. But maybe in that situation I should start thinking more about pre-release versions (e.g. "0.7.18-pre.1"). I'm not even sure if and how these are currently matched by DUB when using ">=0.7.17".

You don't want a pre-release tag for every new commit :)

Comparing with Bundler again. In this case one would be forced to
specify the fully git repository.

Standard bundler:

git "rails", "4.0.0"

Track git HEAD:

git "rails", github: "rails/rails"

Or when it's not on github:

git "rails", git: "git@github.com:rails/rails.git"

http://bundler.io/v1.3/git.html

/Jacob Carlborg

Am 15.09.2013 13:20, schrieb Jacob Carlborg:

On 2013-09-15 12:43, Sönke Ludwig wrote:

Finally got NNTP working :)

Since the default build type is "debug" that should definitely be
included. Executing the equivalent of "dub build" and "dub build
--build=release" for each newly installed package would basically do
this. Once a better build system is in place that would be an option.

As far as I know, the only thing the -debug flag does is enable the
"debug" statements. Most of the use cases I have seen prints some
information to the console. I would really hate to have that by default.
That's only useful when one needs to debug a third party package which
doesn't behave as it's supposed to. I think that by default we should
assume that they do behave as they're supposed to.

What is useful is to have debug symbols, that is the -g or -gc flag.

In this case "debug" means both, -debug and -g/-gc, but I agree that -g
is the important one.

Difficult call with the branches and starting tracking just after the
first version tag. It would be a lot cleaner, but on the other hand
there are a lot of packages now where the author doesn't feel
comfortable yet to start tagging versions (even if that is an
unjustified feeling). IF we end up with half the number of packages by
forcing version tags, that would arguably be worse overall for the
system.

Hmm.. maybe a little psychological trick can help here: non-tagged
packages could always occur after tagged packages in the list
(assuming that they are in a pre-release state) or get some kind of
visual "beta" tag, so that the author is kindly forced to start making
tagged versions to get more people to use their packages.

A "beta" flag or similar might be a good idea. Possibly a button to
show/hide these beta packages. The idea of sorting non-tagged package
last is also good.

We should come up with a better name than "beta" since according to the
semantic versioning scheme you're allowed to have versions like
"0.2.0-beta", "0.2.0-alpha" and "0.2.0-rc1".

Maybe just "unversioned" and slightly grayed out or similar?

True, but I also often have the situation with vibe.d that a quick fix
is needed for someone and making a release would be too much effort.
But maybe in that situation I should start thinking more about
pre-release versions (e.g. "0.7.18-pre.1"). I'm not even sure if and
how these are currently matched by DUB when using ">=0.7.17".

You don't want a pre-release tag for every new commit :)

Comparing with Bundler again. In this case one would be forced to
specify the fully git repository.

Standard bundler:

git "rails", "4.0.0"

Track git HEAD:

git "rails", github: "rails/rails"

Or when it's not on github:

git "rails", git: "git@github.com:rails/rails.git"

http://bundler.io/v1.3/git.html

Okay but that's not that much different from using "~master". I think
the most important achievement is to minimize the number of packages
without version tags. At least I'd assume that people would
automatically stay with version based dependencies if possible when all
they see in the registry has versions.

On Sat, 14 Sep 2013 12:12:02 GMT, Jacob Carlborg wrote:

On Wed, 11 Sep 2013 17:51:56 GMT, Dicebot wrote:

No way. You just can't do it properly without lot of efforts (infrastructure efforts, not development) and introducing yet another broken package manager is not good idea.

It's not that hard, just put all the binaries in a directory and add it to PATH. What's the point in having a package manager that only clones a repository? What does it give me that git already doesn't?

Simply having random folder added to PATH is exactly kind of unhygienic hack I don't like to see. I know that this approach is a usual way to do things on Mac but on my Linux machine I don't want a single binary out of build dir that is not known to core OS package manager ;) It does not matter if it is development tool. I think dub approach with no actual installation but setting required environment instead is more hygienic (if I understand it right).

Also in my opinion simply cloning the repository is exactly what needs to be done in most cases. Language-specific package manager is just some syntax sugar on top which help to pull exactly the repository and tag you need.

On 2013-09-16 15:03, Dicebot wrote:

Simply having random folder added to PATH is exactly kind of unhygienic hack I don't like to see. I know that this approach is a usual way to do things on Mac but on my Linux machine I don't want a single binary out of build dir that is not known to core OS package manager ;) It does not matter if it is development tool.

What so bad about that?

I think dub approach with no actual installation but setting required environment instead is more hygienic (if I understand it right).

What do you mean with "setting required environment"?

Also in my opinion simply cloning the repository is exactly what needs to be done in most cases. Language-specific package manager is just some syntax sugar on top which help to pull exactly the repository and tag you need.

I just don't agree with that. You also seem to keep forgetting that
there are platforms which don't have a package manager installed by default.

/Jacob Carlborg

On Thu, 19 Sep 2013 22:03:40 +0200, Jacob Carlborg wrote:

On 2013-09-16 15:03, Dicebot wrote:

Simply having random folder added to PATH is exactly kind of unhygienic hack I don't like to see. I know that this approach is a usual way to do things on Mac but on my Linux machine I don't want a single binary out of build dir that is not known to core OS package manager ;) It does not matter if it is development tool.

What so bad about that?

It can't be used to satisfy dependencies for other packages. It is not possible to easily query all files belonging to it in a standard manner. It is not applicable for cross-language tools. It offers nothing over existing system built into my OS. It creates inconvenient fragmentation when multiple languages come into question.

I think dub approach with no actual installation but setting required environment instead is more hygienic (if I understand it right).

What do you mean with "setting required environment"?

Instead of installing libraries globally, simply provide required -I and -L switches to dmd upon build based on dependency list.

Also in my opinion simply cloning the repository is exactly what needs to be done in most cases. Language-specific package manager is just some syntax sugar on top which help to pull exactly the repository and tag you need.

I just don't agree with that. You also seem to keep forgetting that
there are platforms which don't have a package manager installed by default.

I remember it but it is not a D problem to solve. Or any other language. It is a common desire among the developers to consider their language a first class citizen and OS a second class one but in practice it is always other way around.

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