DSSS 0.69 released.

[Gregor Richards]

Responses inline. Beware extreme sarcasm.

Bruno Medeiros wrote:
> Gregor Richards wrote:
>> Mike Parker wrote:
>>> Gregor Richards wrote:
>>>
>>>>
>>>> As of 0.69, I will no longer be delivering binaries of rebuild alone 
>>>> - I have decided that doing so is backstabbing my own strategy. 
>>>> Instead, I'm providing a "light" binary of DSSS with no net support 
>>>> on Windows, where there are necessary prerequisite binaries for net 
>>>> support. It's only 300K bigger than the binary release of rebuild.
>>>
>>> Awww! I really have no interest in DSSS or any sort of DSSS-lite. I 
>>> think Rebuild rocks, though. Having the binary available for download 
>>> has been a great convenience. I wish you'd reconsider!
>>
> 
> The following rant caught my interest, because I don't exactly 
> understand what is the usefulness of it (other than the rebuild 
> component), so I decided to look into it.
> 
>> I wrote rebuild as a utility for use by DSSS. That was its primary 
>> purpose in existence. The fact that it can be useful in isolation is 
>> irrelevant.
>>
>> Statements like this annoy me to no end. I create this tool that 
>> integrates and standardizes all sorts of things and makes the whole 
>> situation of using 3rd party libraries infinitely easier with D, and 
>> everybody goes, "Hey, look, it works with a build utility that works 
>> well. Let's use that and not the tool itself. I have no interest 
>> because I don't know what it does and I'm happy with copying all my 
>> libraries into the same directory as the modules for my binary in a 
>> gigantic mess of unmaintainable code. Oh, and including obnoxious and 
>> platform-specific build scripts that use rebuild rather than DSSS, a 
>> tool for making easy and cross-platform build scripts, is brilliant."
>>
> 
> I've read:
> http://svn.dsource.org/projects/dsss/trunk/docs/README.overview
> and indeed the Building component (handled by rebuild I presume?) is 
> definitely useful, as I'm sure there is no doubt.
> 
> As for the Installation component, well in either two cases:
> If you just want to use the software (the binaries, not the source 
> code), then OS facilities should be used to install/uninstall the 
> software, not something as specific as DSSS.

In the rare case that that's easy and generic. That rare case being 
true, oh, 0% of the time.

There really is not an OS facility for installation that isn't a PITA. 
You notice that Makefiles just install with 'install', which makes 
non-uninstallable installations. Weeh. DSSS may maintain the manifest 
itself, but at least it /maintains the manifest/.


> If you want to use the software's source code, then you should be able 
> to "install" it just by unpacking an archive file, and "unistall" it by 
> deleting said archive/folder. As for dependencies, see bellow:

God I hate this logic. I've seen it so many times, and it doesn't get 
any less sensible.

1) Have fun doing that with tioport. Awesome for every SWT app to take 
ten minutes to compile because we're living in the pre-library stone ages.
2) Have fun doing that with derelict components. SDL-somefeature and SDL 
magically merge into one library, and without going and looking up which 
files are which, you can only uninstall the whole blob.
3) Have fun doing that with twenty dependencies. Lesse, this one is in a 
'src' directory, this one is over in this corner but oh that actually 
needs to be installed from this directory, not that one, this one is -- 
ahh, fuck it, I just won't use any dependencies, I'll write the entire 
thing without using anything. OR, if those libraries used DSSS, I could 
either `dsss net deps` or build and install them in a CONSISTENT WAY. 
Consistency? Yes. Consistency. It's impossible to make tool builds and 
installs consistent with scripts or the "copy-and-paste to install" mindset.

Yes, in some limited cases this works. But it's hardly a generic 
solution - the generic solution should work for both simple and complex 
libraries, for both few and many dependencies. Boy, I wish somebody 
would write a tool like that! Oh yeah, somebody did - DSSS.


> 
> As for the Acquisition component (note, I'm not familiar with Perl's 
> CPAN or Ruby's Gems) :
> Again, if you just want to use the software, then OS-specific facilities 
> should be used, otherwise it's just reinventing the wheel (is this even 
> an intended use-case?)

In the rare case that they're available, yes. It's primarily for libraries.


> If it's to mess around with the source, I am of the opinion that a given 
> project distribution should have all of it's dependencies in the 
> distribution as well (headers + binary libraries).

I'm inclined to respond with an insult. But I won't, because that's mean 
and a lot of D developers seem to be trapped in this ridiculous mindset. 
While I know you're never going to change your stance, I'm hoping that 
other readers will go "Oh, that makes sense" and not disown my methods 
because I'm a jerk.

Have fun maintaining ten branches because you're unwilling to handle 
dependencies properly. Oh, <X> fixed some file foo.d so that it works on 
Mac OS X now, I should retry <Y>! ARGH! Now I have to delete the version 
in the maintainer's archive, copy in the --- damn it, which derelict 
libraries were in there? Boy, I'm glad he just copies and pastes 
dependencies, makes my life a beautiful living hell.


> For example my last 
> C++ project had SDL, DevIL, GLUT, GLEW and some other deps all bundled 
> in.

Wow, that's disgusting and unmaintainable. Have fun following the 
changelogs for all of those and re-duplicating.


> It's just simpler that way.

Oh yeah, and also disgusting and unmaintainable. But yeah, simple.


> The only problem I see with this 
> approach is redundant disk space

Sooo, maintaining what is effectively a zero-modification branch just 
takes disk space, no developer time or effort. Got it.


> , which is hardly significant.
> The only scenerio I'm seeing where DSSS could be useful, is when I have 
> project that *I* am developing (ie, not a third part project),

So, not useful for the third party who would just like to build against 
the latest, presumably-least-buggy versions? Got it.


> that has 
> a lot of dependencies, *and* where I would want to update those 
> dependencies often during the course of development. And even then, it 
> might be just as easy to have a shell script that downloaded the latest 
> versions of said dependencies, and unpacked them.

$ dsss net deps
$ wc -l stupid_downloader_script.sh
103765


> So explain to me a scenario where DSSS is useful. :)
> 

Yeesh.

[Note to spectators: Gregor is not a crotchety old man. He is mean and 
sarcastic, but lives a happy life and is an optimist :P ]

  - Gregor Richards