DSSS 0.69 released.

[Bruno Medeiros]

Gregor Richards wrote:
> Responses inline. Beware extreme sarcasm.
> 

Don't mind sarcasm as long as your arguments are clear.

> 
>> 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.

Who said anything about compiling dependencies? That wasn't my 
intention, I did mention below that dependencies where in the form of 
"(headers + binary libraries)".

> 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.
> 

A project with *twenty* dependencies? Well, yes, in that case it's very 
likely DSSS would be quite useful, as I mentioned in my previous post.

> 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.
> 
> 

Yes this is not a generic solution, and it isn't preferable for all 
cases. My contention is just on how often it is preferable or not. I 
would say it is more than just "in some limited cases".


> 
>> 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.
> 

Don't be so sure about my stance. I'm trying to understand more 
scenarios where DSSS would be clearly preferable.

> 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.
> 

Ten branches? You mean one branch for each dependency? Or you mean ten 
branches of your own project? What is <X> and what is <Y>? I don't 
understand that situation.

> 
>> 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.
> 
> 

Why is it disgusting and unmaintable? Where would I re-duplicate? What's 
the trouble with following changelogs?

>> 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.
> 

What do you mean a zero-modification branch?

> 
>> , 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.
> 
> 

If they wan't to use the latest, presumably-least-buggy versions, then 
just download the new library binaries and replace the old ones. That's 
in the case where there are no API changes of course.

>> 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
> 
> 

A download script with 103765 lines, right... Did you program an AI to 
download a file?
Right now I'm not imagining a download script more complex than either 
doing an svn/cvs checkout, or using wget to download an archive, and 
unpacking it. I'm not saying there wouldn't have to be more complex 
scripts, I'm saying I'm not imagining anything more complex.
Note that I'm talking about a script *specific* to a given project, made 
by the project's coders, not a generic script that would determine 
dependencies for any given project and download them (ie., dsss net in 
script form).


/* ----------  And now, on the binary installation issue  ---------- */


 >>
 >> 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.
 >

Rare case that they're available??... What kind of context are you 
talking about?? Maybe I'm hallucinating, but I find that most software 
(including libraries) has precompiled binaries for the common platforms 
(Windows, Linux, MacOS).

 >> 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/.
 >


"In the rare case that that's easy and generic." ? Again, what world do 
you live in?
Ever heard of an OS called Windows? Altough it sucks in a lot of things, 
it's software installation/uninstallation facility is not one of them. 
It's quite nice in fact. <sarcasm> There are also rumoreds sightings of 
mythical beasts such as "Gentoo" and "Ubuntu" which have proper OS 
installation facilities. They say they even allow uninstallation of 
software *gasp*. But like most legends, it's likely to fantasious to be 
true.... </sarcasm>.

Ok, seriously now. Make install?!? C'mon! Make install is not a facility 
for installation. Make install is not a proper facility for anything. 
Make install is an hack for OSes without proper install facilities, used 
by ugly and "hacky" software distributions who think that spreading 
seven pieces of the software across different locations in one's 
computer is a good thing.
Yes, this might go against traditional UNIX wisdom, but, as you can see, 
there are many things in this traditional "wisdom" I don't like, 
particularly with regards to file system structure.


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D