On 2/06/2015 1:11 a.m., Adam D. Ruppe wrote:
> On Monday, 1 June 2015 at 10:24:46 UTC, ketmar wrote:
>> and now you killed the only sensible way to use it: as package manager.
>
> I don't care for it as a package manager either because it is too
> complex. As you know, I like to do my things as individual files. I
> don't go through the pain of making a new github repo with a gigantic
> folder layout for every little thing.
>
> One of the things I really like about D is how modules are encapsulated
> into individual files. The code is there, the documentation is there,
> the tests are there. No separate headers or anything else.
>
>
> The only package management scheme I'd even consider using is one that
> has a per-file option... and even then, I probably wouldn't bother
> because individual files are so easy to manage anyway that downloading a
> new program to use them doesn't exceed the "existing option is good
> enough for me" threshold.
>
>
> But even if I don't use it myself, it would be kinda nice if the
> repository could handle my files just so I can toss it up there and not
> have to answer questions about that anymore. I'd be willing to add them
> all individually to the repo, even listing the dependencies manually if
> I had to (tip: make this a web form that I can just submit to add stuff
> to it, no json upload).... but I'm not willing to separate my little
> repo into 25 other repos and separate my folder into 125 other folders
> to be added to it.

Something I've thought about but haven't suggested up to now is making dub-repo to support personal projects.
Basically one repo per person preconfigured if e.g. Github/Bitbucket is specified.

github.com/rikkimax/dubcode

Just as an idea for what I'm meaning url wise.

So then when specifying a dependency in dub, its just a matter of saying <person>:<subproject>

It would also help with people having there own util libraries all listed.

Of course then you'd only have to dump your code in there and have a dub file with each file being its own sub package.

Seems simple to implement, but idk if it is the answer.

I think the way I'd do it is you still make projects in the repo that are referenced like normally, just it refers to a file in a specific repo instead of a whole repo.

Maybe using the subpackage feature it can get close enough. I'll try using an empty source folder then do the others as a single additional file.

But actually, the multiple listing on the repo is the most important part to me, these are really individual things, they shouldn't be listed as "miscellaneous from me" on the listing...

On Monday, 1 June 2015 at 05:05:21 UTC, Brad Anderson wrote:
> On Monday, 1 June 2015 at 04:36:06 UTC, Andrei Alexandrescu wrote:
>> On 5/31/15 8:48 PM, Manu via Digitalmars-d wrote:
>>> As for dub, I'd use it if it worked like a package manager; dub get
>>> libcurl-d libqt-d zlib-d libsdl2-d etc
>>> I have no use for it as a build system, and therefore it's expression
>>> of dependencies is no use to me. I just want something that works the
>>> same way as '-dev' packages already work perfectly well in linux, that
>>> is, they fetch headers and libs, and put them in a standard location
>>> that all the tooling can find.
>>
>> I thought it does that.
>>
>> If dub doesn't allow me to type one command to download and install all I need about a package, we need to add that pronto. I consider it a dealbreaker.
>>
>>
>> Andrei
>
> dub fetch does this already (though probably not quite what you are thinking of). You'd need to specify the paths manually because if it installed them to the global compiler paths we'd have dependency hell (what if 5 projects I have need 3 different versions of a library?). Also, you'd need root permissions.
>

I wonder if essentially hashing a library(ultimately each file) could be used to avoid dll hell. Essentially hash the .d files and then different versions will have different hashes. When you compile your project and it is successful, the compiler/linker can write a configuration file that includes the hashes of the various files used. This then could be used to avoid dll, if one has a proper way to "check" for versioning(online database) then one can find the proper versions.

Obviously small changes to any d file, even if it is non-breaking will change the hash. This is not a bad thing but since there will be no correlation between hashes and versions one must have a database of versions and their hashes.

The good thing is that if, say, a project doesn't compile after updating a "library" to the "wrong" versions, the configuration file won't be modified since the compiler won't be able to compile the code. One can then easily use the (old) config file, if it exists from a previous (working) build, to deal with the versioning issue. (e.g., hash is different for mylib.d, means wrong version. Get correct version)

In fact, maybe the way to go is for the config file essentially to keep a history of several last working builds, e.g.,

05/31/15 - mylib.d[3FAB9999ABCCC34C3C] - Compiled OK
         - myotherlib.d[4C934DFFFFFFF34C3C] - Compiled OK
         - myproject.d [FFABC33CCA4367C4EE] - Compiled OK
         - Project [3493493428439294292] - Compiled OK

06/01/15 - mylib.d[3FAB9999ABCCC34C3C] - Compiled OK
         - myotherlib.d[4C954D5F3F2F434EEC] - Compiled OK
         - myproject.d [FFABC33CCA4367C4EE] - Failed
         - Project [3493493428439294292] - Failed

In the above case, the myotherlib.d's hash changed. the project did not compile. Hence we have a versioning issue. It is easy to see what the problem is. One then simply needs an online datable to match the hashes to the versions or simply search all "versions" and hash them.

Also, one benefits from simply hashing any file to get it's "version". If you had 10 myotherlib.d files from the past but don't know which is which(different copies scattered across different backups, etc), simply hashing them and finding the correct one(in this case, 4C934DFFFFFFF34C3C) can be used to get the project working again.

Since most of this stuff can be automated, it seems like it would be a better way to deal with versioning than the standard methods which relies on users correctly defining the versions and maintain them.

On Monday, 1 June 2015 at 13:11:43 UTC, Adam D. Ruppe wrote:
> The only package management scheme I'd even consider using is one that has a per-file option... and even then, I probably wouldn't bother because individual files are so easy to manage anyway that downloading a new program to use them doesn't exceed the "existing option is good enough for me" threshold.
>

What happens when you find a bug in your library? Then every user has new work to do to merge the changes. With DUB you don't do a thing for patch versions in user code. _This provide a way to warn your users and make them upgrade_. This is the main interest of DUB.

You could use git submodule for that, but not everyone use git, and not everyone want to search commit logs for the right version.

On Monday, 1 June 2015 at 14:09:32 UTC, ponce wrote:
> What happens when you find a bug in your library?

Users still have to test bug fixes because what I consider a bug they might consider a feature. I dread software updates not because downloading a file or applying a patch is hard, but because I fear unrelated and/or silent breakage.

On Monday, 1 June 2015 at 06:20:18 UTC, Nick Sabalausky wrote:
> Ditto. Dub's great if you let it be your buildsystem, but as soon as you want to use it as a package-manager-only it becomes an uphill battle with dub fighting back every step of the way (I speak from experience). That problem is worse if your project is a library that you want fetchable through dub.

And this is when Jacob Carlborg chimes in and says "I told you so." ;) His favorite complaint about dub has always been that it combined package management and the build tool into one.

dub works fantastically if you want to do everything in the standard way without any funny stuff, but it clearly doesn't have the power of a tool like make, cmake, etc. As soon as you need to do anything funny - like include anything related to other languages in your build, or put things in a specific layout because of some company-specific thing, or anything that wasn't explicitly planned for by the folks writing dub, dub just won't work.

Now, to be fair, I don't know how you can be pulling in all kinds of stray libraries with who-knows-what for their build systems and expect it to work very well via a single tool (at minimum, you have the problem that the machine that you're trying to build them on will likely be missing some of those tools), but that's pretty much what we need to handle the general case. Without that, dub will work great for the normal case (which _will_ be plenty for many, many projects), but it won't work in the general case - and corporate folks in particular are probably going to have to skip out on using it because of abnormal requirements on their part.

Even simply splitting dub out so that it can pull in packages without necessarily being able to build them would be nice (maybe adding a flag to the dub.json file indicating whether dub can be used as a build tool for the project or whether it's supposed to just act as a package manager for it), though that does add the problem of code.dlang.org becoming more confusing, since you wouldn't be able to rely on all projects on it being built for you by dub as part of the process of grabbing packages.

It's a complicate problem, and dub went a route which works in the 90% case, but doesn't work for more complicated cases, which will make dub unusable for some projects - especially corporate ones. I don't know how fixable it is without a major redesign of dub.

- Jonathan M Davis

On Monday, 1 June 2015 at 13:03:28 UTC, Adam D. Ruppe wrote:
> Writing to something that requires root is just doing it wrong IMO, unless the user specifically opts in to it.
>
> /usr/anything is thus wrong, it should all be done locally. My preference is actually right in the current directory, do it on a per-project level. But if you must go higher, the user's home directory is also acceptable.

I believe Manu was referring to (system) package managers. Those that are run by users (like rubygems/bundle, pip, dub) must of course never write outside the users' home directory.

On Monday, 1 June 2015 at 12:34:47 UTC, extrawurst wrote:
>> dub is a good package manager, but it's not a good build system. For small projects that just want to list dependencies and have it build, it's sufficient. Any larger project will have needs that won't be easily solved by using dub. Which is why I wrote my own.
>>
>> Atila
>
> Hi Atila,
>
> you are talking about cross language builds ?

That too.

> Other than that limitation, what do you miss ?

Everything I could do (and have) in cmake. Here are two really simple examples:

1) Automatically run a script to generate the file containing "main" before doing the build, with proper dependency tracking
2) Concurrently building release and unittest builds

I've worked on complicated build systems before, I know the kind of thing I'd need.

> I have a couple of rather sizable projects running with dub without problems and one could argue vibe.d is a pretty big project too which works fine.

I wouldn't consider vibe.d to be a large project.

> The D community already suffered enough from not uniting workforces behind at least SOME standards (hint at tango), a plethora of options for newcomers to choose from for basics like building is also daunting IMHO.

I fully support dub being the default package manager and for most people/projects it is a good enough build system. That's why my build system builds on dub instead of wanting to replace it. It leaves the package dependency part to dub and focusses on build descriptions that can leverage dub's existing knowledge of the build.

Atila

Since this thread seems to have turned into a wishlist for dub features, I'm going to add one:

Undeprecate dependencies on git branches. They are really not different from dependencies with fuzzy "~>" versions. For both, the exact selected version can be stored in dub.selections.json.

Use case:
Making a fix to a third-party project and sharing that fix with other team members. Having to create a temporary project on code.dlang.org just for that purpose is both a waste of time for developers and a waste of resources of community infrastructure.

On 5/31/15 7:01 PM, Andrei Alexandrescu wrote:
> Let's make this part of 2.068:
>
> https://issues.dlang.org/show_bug.cgi?id=14636
>
> It's preapproved. Who would want to work on it?

Just a reminder to everyone that at one point, we wanted the compiler to do kind of what 'dub' does -- fetch packages as dependencies for a project. Remember this DIP? http://wiki.dlang.org/DIP11

The problem I have with dub is it makes you as a consumer of libraries live within its realm. You have to make a dub file to use it, and that's not a small burden.

That being said, can we get a tool that does what DIP11 asked for by using dub? We do have quite a large repository of code that's dub-enabled, and I have no problem requiring extra steps for *libraries* to make them usable with this system. Basically, a builder that says "hey, if dmd (or whatever) cannot find an import, see if dub can do it, and then use dub to download the package".

-Steve