On 2016-01-08 8:08 AM, Stephen Chrzanowski wrote: > For the record, *I* personally prefer trying to get all essential resources > built directly into my final output (For SQLite, default database > structures, SQLite strings, and maybe that one day, SQLite itself), that > way I'm in control of what the application does, and have no reliance on a > 3rd party update to a resource file that breaks my code. That is just my > preference, and old school or not, I prefer working software, not software > that might work after MySQL updates and breaks a resource I require when my > application doesn't touch MySQL, or when a user deletes a critical file my > application requires and claims they didn't do anything .... I've > never had 100% success on a fully independent database driven application > (SQLite or not), and that is perfectly OK. That doesn't mean I'd like to > strive for that one day.
You are or seem to be talking about 2 different things in this thread. I very much agree with you that it is reasonable for an APPLICATION to bundle its key dependent libraries in ITS executable so the proper functioning of the application is insulated against many changes to system-provided or separately installed libraries. Especially today with abundant disk space. But what you seemed to be arguing for before was that a programmer tool for making applications, that is Perl itself or R itself or what have you should be bundling SQLite with it, and this I disagree with. The user base of programming language environments is programmers who are making applications, and it should be those users' decision to bundle SQLite with their application, and not having it forced on them by the creator of the programming language to include SQLite with all applications regardless of whether it is used or not. Apples and oranges. -- Darren Duncan
