On 2013-09-26 13:39, Dicebot wrote:

> No, you just let maintainers interested in target systems to take care
> of it. And package for 2-3 you care about _personally_. It is an
> obsolete idea that developer of a library/program should do any
> packaging at all. If your program is any good, there will always be
> volunteers to adapt it nicely for their beloved systems.

Most developers/packagers/people don't even know about D. They know even less about my projects. Be realistic.

> Yeah and what you propose is like mandatory requirement to have a
> separate home for every single electronics vendor. Want to buy something
> from different one? You must buy new home for it, period. (Well, feels
> like we are actually going there in real like >_<)

I'm just being realistic. Most of these packages won't ever end up in a system package manager.

>> It's the same with dub. I install a package to use the tool. But wait,
>> it actually _don't_, it just clones the repository. I have to figure
>> out myself how to compile and install the tool. It's only half way there.
>
> This is just plain wrong. dub takes care of proper compilation of any
> tool that is contained in its registry, you don't need to do anything
> about it.

It does _not_ compile packages using "dub install". At least not the one I created. Yes, it could compile it without any problem. It just doesn't do that when you run "dub install".

> But there is no possible legitimate reasons to install it.
> During development you can pretty much run in locally from the source
> dir. For end user distribution you must go system-specific way.



> It is neither a build tool nor package manager. It is a tool that
> aggregates different possible build tools backends and takes care of
> resolving build dependencies for them. Nothing more, nothing less.

It advertise itself as a package manager.

-- 
/Jacob Carlborg

On 2013-09-26 15:53, Bruno Medeiros wrote:

> You have to install the yourself, yes. Not compile it. Dub should take
> care of the compiling aspect.

Have you tried it? It does _not_ compile a package when running "dub install".

> If you just want to use the tool executable artifact, dub is likely not
> right for you.

That might be the case. I'm just seeing this as a great opportunity to use libraries and tools for development.

> If the tool requires more complex installation, the tool
> developers should provide their own installer or OS distribution package.


> A build tool should not download anything? That is antiquated C/C++/make
> way of thinking. Popular build tools for modern languages all do
> downloading, for example Apache Maven (for Java), Gradle (for lots of
> different languages), and even RubyGems.

I just think that should be a separate tool.

> You might say RubyGems is a package manager, and not a build tool. But
> in practice it is both actually, even if it is not called a build tool:
> It fullfills the the equivalent goal as structured build tools like
> Maven or Graddle do for other language, the distinction is only less
> clear becase Ruby as a language can be easily interpreted and does
> require an overt "compilation/build" phase to generate an executable.
>


-- 
/Jacob Carlborg

On 2013-09-26 13:17, Dicebot wrote:

> Good look getting all those small trivial libraries into official
> repositories. Actually, some distros even prohibit pure source packages
> at all.

That's exactly why dub _should_ install packages. If you don't like, don't use it.

> You should install it because you are tired of satisfying build
> dependencies manually and it is a bit more robust than git submodules.
> Pretty much all.

How is it more robust than git submodules? It does basically the same.

-- 
/Jacob Carlborg

On 2013-09-26 16:16, Bruno Medeiros wrote:

> Are... you... serious?... O_O
>
> There are incredibly important benefits for development-time usage.
> To automatically fetch the required dependencies, making sure they are
> correct for you application. Easily upgrade the version of dependencies?
> Support multiple build configurations (including for example unittest
> runners)?


> Supporting all the previous functionality in a way that is
> replicable across different machines?

It's not, that's another big issue with dub. It doesn't lock the dependency graph. If you have the packages:

My own package:

{
    "name": "foo",
    "dependencies": {
        "bar": "=0.0.1"
    }
}

Third party package:

{
    "name": "bar",
    "dependencies": {
        "xyz": ">=0.0.1"
    }
}

Another third party package:

{
    "name": "xyz"
}

Say I install package "foo" on a machine. It will install package "bar-0.0.1" and "xyz-0.0.1" just as it should. Then an hour later I install the same package, "foo", on a different machine. Then suddenly it install "xyz-0.0.2". Surprise surprise, it's not the same application anymore and you have no idea if the application is working or not.

Of course, it's unlikely this will happen within an hour. But try six months later and you might end up with a completely different application.

> Have other tools such as IDEs  understand the source and build structure of your
> application/project/library??
>
> System package managers don't support this because they are not
> cross-platform. Even if cross-platform wasn't an issue, there might
> still be several shortcomings or inadequacies with OS package managers
> because they are more often geared torwards end-user installation, not
> development-time usage.

I'm not saying that all other features are not useful but I'm saying that it doesn't actually install the packages is a big issue.

-- 
/Jacob Carlborg

On 2013-09-26 10:39, Manu wrote:

>     http://code.dlang.org/
>
>
> Is that not a package list?
>
> I only just skimmed this thread, but it seemed dub installs packages to
> me...
> What did it install when I told it to install vibe.d and some other
> companion pieces then?

If you run "dub install" it will only clone the repository and its dependencies. It will not compile anything and it won't put the resulting binaries (which don't exist) in a easily accessible location.

Although it can be useful to integrate in an IDE, but that will only be useful for libraries. Not for executables, since they're not installed.

-- 
/Jacob Carlborg

On 2013-09-25 18:14, Bruno Medeiros wrote:

> But this is all for development-time usage. To have the same tool try to
> be an executable installation manager is another thing entirely and, in
> my opinion quite ill-suited for dub (see related OP). Where did this
> idea even come from??

We can take Eclipse as an other example. It has a built in package manager for plugins. Would you prefer that it just downloaded Java source files. Then you have to manually build the plugin and figure out where to place it to have Eclipse recognize it?

-- 
/Jacob Carlborg

On Friday, 13 September 2013 at 16:09:11 UTC, Sönke Ludwig wrote:
> Something like:
>
> def somevar="somevalue"
> libs "$somevar"
>
> or
>
> template "sometemplate" {
>   libs "gdi32" "user32"
> }
>
> configuration "gui" {
>   mixin "sometemplate"
> }

A little redundancy doesn't hurt so long as the overall package description remains concise and simple.

On Thursday, September 26, 2013 22:05:35 Jacob Carlborg wrote:
> It's not, that's another big issue with dub. It doesn't lock the dependency graph. If you have the packages:

This is definitely something that needs to be sorted out.

- Jonathan M Davis

On Thursday, September 26, 2013 15:20:53 Bruno Medeiros wrote:
> I just don't think dub should aim for that goal. It should mainly be a build tool and package manager for development-time usage.

Agreed. I don't think that dub should have anything to with installing programs or installing anything in the system at large. IMHO, it should be solely for development. At most, it should be set up to collect all of the libraries needed for running the application so that you know what you need when actually creating a system package for your application.

- Jonathan M Davis

Am 26.09.2013 15:35, schrieb Chad Joan:
> On Tuesday, 10 September 2013 at 20:48:58 UTC, Andrei Alexandrescu wrote:
>> We've been experimenting with http://code.dlang.org for a while and things are going well. In particular Sönke has been very active about maintaining and improving it, which brings further confidence in the future of the project.
>>
>> We're considering making dub the official package manager for D. What do you all think?
>>
>>
>> Andrei
> 
> I hate to be /that guy/, but...
> 
> Sönke, have you considered using TOML as an editable serialization/configuration format? https://github.com/mojombo/toml
> 
> It's easy on the eyes, has a simple grammar, and seems to have at least /some/ buy-in from other communities.
> 
> I'm just not sure if it has all of the features you desire; you would know better than I.

I think as a configuration format that makes a lot of sense. However, it looks like it may get tricky/impossible to define lists of complex entities, such as for the "configurations" section.

Also SDL has the not to be underestimated advantage of allowing the
repeated use of the same tag to define lists, which cuts down the
nesting level by one for each such list, or allows to define constructs
that have a more imperative feel to them (rather than purely declarative).

Maybe the example [1] could also be adjusted for TOML to get a better feeling for it, though.

[1]: http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2/