On 2013-09-11 18:11, Sönke Ludwig wrote:

> It will only look at version tags of the form vA.B.C(postfix) any reason
> to hide one of those? It could be added as a feature to the registry,
> but is there a compelling use case to warrant the costs?

No, that should be ok.


> "or", you can choose which using "dub --config=library" or "dub
> --config=application" (the default).

Ok, I see. I got confused by the documentation:

"Automatically detects the target type. This is the default global value and causes dub to try and generate "application" and "library" configurations"

It says '"application" and "library"'. I think you should update to say "or" to avoid this confusion.

> Works for me, but master was broken for some hours. Maybe you caught a
> bad version?

No, I don't think so, I was using 0.9.17. What's the expected output/file(s)?

> I just don't know if that can be generalized to everyone or at least the
> majority of users. Maybe this is a good topic for starting a wider
> discussion/poll.

When you start using enough packages it will cause problems.


> If used correctly, by definition, it _does_ help. Reality, especially in
> the fast moving D environment, may be different, though. However it
> seems to work quite well in the C world.

It helps, but it won't fix or make the problem go away.


> By upgrading and getting updates of indirect dependencies, even if the
> main package wasn't updated.

Then you get specify that instead in the dependency list. Most often I don't care about indirect dependencies, as long as everything works. If I get a new version of an indirect dependency it would be, most likely, through a direct dependency.

> Note that I definitely don't oppose to the idea of integrating such a
> mechanism -- I do see the value. The question is if it should be the
> default or not (Bundler is opt-in after all), taking into account for
> example how well it interacts with branches and different use cases. I'm
> quite open there, but I first have to play that through with all of my
> stuff before I can voice an opinion.

Bundler is required when using Ruby on Rails. I just don't want everything to break at random just because it's a month later a new version of a package is released.

-- 
/Jacob Carlborg

On 2013-09-11 18:50, Brad Anderson wrote:

> I have to completely disagree with you here.  Where would it end?  Would
> it install vim for me?  Install the Java VM so it could run some Java
> tool?  The level of effort needed to add this functionality—which would
> duplicate dozens of existing package management systems that already do
> this job well—is not worth it (and that's before you even consider the
> amount of effort that would be needed to maintain such a system).
>
> dub handles source libraries and handles them well (for such a young
> project).  There is no need to make it do everything and I think trying
> to would be detrimental.

Then we can remove all target types except for "sourceLibrary" because they're all a lie. Currently when "installing" a executable package it will only clone the repository. Then I have to figure out myself how to install, which shared libraries it may depend on, which directories they should be put in. Basically leaving the task of the package manager to the user.

-- 
/Jacob Carlborg

On 2013-09-11 14:33, Dicebot wrote:

> I am strongly against it. It is not a job of language package manager.
>
> Implementing it properly will require to integrate the knowledge of
> every existing packaging system among every slightly popular OS /
> distro. Implement it as a hack with own package ecosystem and people
> will hate you.
>
> It exists to simplify development. Users that run D-based programs
> should never ever be even aware of such thing as `dub`.

No, I completely agree. But there are a lot of developer tools that are executables. They are used by developers just as dub is. It doesn't need to be integrated with the native package manager. Just install it in a directory and put it in the PATH.

-- 
/Jacob Carlborg

On 2013-09-11 22:07, Dicebot wrote:

> Different front-end versions are not guaranteed to be ABI compatible.
> You always need to use same compiler version within one application and
> using library that is not updated to latest version forces you to use
> that old version in your own code too.

Yes, what's the problem? That exactly what this kind of tool should be able to handle, if needed.

-- 
/Jacob Carlborg

On 2013-09-11 22:15, H. S. Teoh wrote:

> How would it know which compiler(s) to use to compile the packages? What
> if you have multiple compilers / development environments with
> incompatible ABIs?

The same way it works now.

-- 
/Jacob Carlborg

On Wednesday, 11 September 2013 at 20:16:52 UTC, H. S. Teoh wrote:
> On Wed, Sep 11, 2013 at 10:07:02PM +0200, Jacob Carlborg wrote:
>> On 2013-09-11 17:09, Dicebot wrote:
>> 
>> >Those should be provided as sources and built by dub too.
>> >Distributing binary packages requires both package signing and
>> >reasonable web of trust - something that is not easy to "just
>> >implement" from scratch.  Otherwise any single malicious package may
>> >ruin reputation of the whole system.
>
> The same can be said of malicious source code. Just because it wasn't
> precompiled for you doesn't mean you're going to read through every line
> to ensure there are no malicious bits before compiling and using it.
> Using the package at all -- regardless of whether it's source or binary
> -- implies a certain level of trust already.

Source packages are never trusted by default. It is your (and community) responsibility to verify the source if it is important. Or just ignore the possible consequences if it is not worth it. Contrary to this, binary package does not leave any verification options and in absence of any package signing / trust network one has no other choice but to always consider those harmful.

It is subtle but important difference. As far as I am aware, all major Linux distributions have rather complex infrastructure that assures basic package safety. It is imperfect, of course, but any custom system will be far far away even from that.

On Wednesday, 11 September 2013 at 20:24:26 UTC, Jacob Carlborg wrote:
> On 2013-09-11 22:07, Dicebot wrote:
>
>> Different front-end versions are not guaranteed to be ABI compatible.
>> You always need to use same compiler version within one application and
>> using library that is not updated to latest version forces you to use
>> that old version in your own code too.
>
> Yes, what's the problem? That exactly what this kind of tool should be able to handle, if needed.

Erm, the problem is that developers always want to use latest compiler version with all that shiny features and library that forces him to rollback to old version must be _really_ important to even be considered as a valid option?

On Wed, 11 Sep 2013 16:11:10 +0200
"John Colvin" <john.loughran.colvin@gmail.com> wrote:
> 
> Why not YAML? It's cleaner than JSON and is very widely known.

It often looks cleaner, but the syntax is surprisingly complicated, and the symbols/operators can be difficult to remember.

Am 11.09.2013 22:30, schrieb Dicebot:
> On Wednesday, 11 September 2013 at 20:24:26 UTC, Jacob Carlborg wrote:
>> On 2013-09-11 22:07, Dicebot wrote:
>>
>>> Different front-end versions are not guaranteed to be ABI compatible.
>>> You always need to use same compiler version within one application and
>>> using library that is not updated to latest version forces you to use
>>> that old version in your own code too.
>>
>> Yes, what's the problem? That exactly what this kind of tool should be
>> able to handle, if needed.
>
> Erm, the problem is that developers always want to use latest compiler
> version with all that shiny features and library that forces him to
> rollback to old version must be _really_ important to even be considered
> as a valid option?

Not really, on my enterprise world, things move really really slowly.

Just as an example, last Friday I was helping to sort out a problem with JBoss 4.2.2 (released on 2008).

--
Paulo

On Wednesday, 11 September 2013 at 20:34:05 UTC, Paulo Pinto wrote:
> Not really, on my enterprise world, things move really really slowly.
>
> Just as an example, last Friday I was helping to sort out a problem with JBoss 4.2.2 (released on 2008).

I know, had my own unpleasant encounters with enterprise world. But it is not the case in D reality with no LTS releases. Literally everyone is trying to use latest versions for new projects simply because too much stuff is added with every new version and using any old one is always personal risk.

That does not mean that package manager should not support compiler versioning - that was an answer to Jacobs question why library author should care about keeping it up to date with latest frontend.