← Back to team overview

coapp-developers team mailing list archive

Re: Another kind of package.

 

ES>> I dunno - some things unix doesn't get right in my opinion.  Any reason not do to <package>/<package-version> - so you have wordpress with your 15 million versions inside named wordpress-1.5 and wordpress-2.0 etc etc etc.

Well, the only reason I can think of, is that in the spec currently, for include/doc/resources directory I use a model like this:

├───include
│   ├───openssl       [SYMLINKS to openssl-0.98i]
│   ├───openssl-0.98h
│   ├───openssl-0.98i
│   ├───zlib          [SYMLINKS to zlib-1.23]
│   ├───zlib-1.22
│   └───zlib-1.23


That way you can always point to a well-known-location:

[%PROGRAMFILES%\Common Files\CoApp\include\zlib]

For header files, and

[%PROGRAMFILES%\Common Files\CoApp\lib\zlib.lib]

For the library, and always get the latest installed version.

G

Garrett Serack | Open Source Software Developer | Microsoft Corporation
I don't make the software you use; I make the software you use better on Windows.

From: coapp-developers-bounces+garretts=microsoft.com@xxxxxxxxxxxxxxxxxxx [mailto:coapp-developers-bounces+garretts=microsoft.com@xxxxxxxxxxxxxxxxxxx] On Behalf Of Garrett Serack
Sent: Tuesday, April 06, 2010 1:37 PM
To: Elizabeth M Smith
Cc: coapp-developers@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Coapp-developers] Another kind of package.

>> I don't think it's really a "web library" if you have to edit it.

Good Point.

>> maybe we just need to always put the neutral stuff in just plain program files.... sigh
Me too... *sigh*

The other choice is to make another [\Program Files (any)] to go along with [\Program Files (x86)] and [\Program Files] to indicate architecture independent program files. (perhaps find a different word than 'any'.... 'All' , 'xNN'... I dunno)


>> hehe - I just want to play with code... really.

Me too... *sigh*  *sigh*  *sigh*

I'll be pushing some of my toolkit code for CoApp into bzr over the next couple of days. I've got the license and readme files in there!

G

Garrett Serack | Open Source Software Developer | Microsoft Corporation
I don't make the software you use; I make the software you use better on Windows.

From: Elizabeth M Smith [mailto:emsmith@xxxxxxxxxxxxxxxxxxxxxxx]
Sent: Tuesday, April 06, 2010 1:08 PM
To: Garrett Serack
Cc: Trevor Dennis; coapp-developers@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Coapp-developers] Another kind of package.

On 4/6/2010 4:00 PM, Garrett Serack wrote:
ES>> Except then you run into things that AREN'T web apps being written in a web language using a library.
ES>> PHP-GTK and PyGTK scripts, pyrus/pear packaging code, phpunit test suites
ES>> - they all want to use libraries that aren't necessarily confined to web space.

TD>> For libraries, should we have a "Program Files\Shared" type of directory?  Similar to the /usr/share on UNIX? Or Libraries?


For non-web apps, I had specified a place for common things ( see http://coapp.org/Blueprints/Packages/1._Common_Package_Blueprint )

The pattern works pretty good for shared libraries or components that are designed to be immutable.

Zend Frameworks and PEAR libraries really fall into that category.

Yeah, I think so too - you don't edit ZF and PEAR , you just use them ;)  As long as you can do multiple versions of them sounds good.


I'd also argue shared web libraries that are not intended to be modified should install in Program Files\<publisher>\<product> like everything else.  The only down side is that it's less discoverable, nor is it likely 32-bit / 64-bit specific. (and MS in their infinite wisdom didn't give us a platform-neutral program files directory. That's gonna bite us 10-20 years from now.)

I think web libraries which are likely to be subject to some editing/modification should still go in inetpub.
I don't think it's really a "web library" if you have to edit it.  If you have to change files to make it run, it's an application.  And the platform neutral thing has ALREADY bit me in the butt (stupid (x86) at the end of program files) - maybe we just need to always put the neutral stuff in just plain program files.... sigh

Hmmm. Still gonna have to think some more.

Oh, and I was going to agree with <package>\<version> ... it means less repetition, but it's inconsistent with the layout for docs & include folder in the common package blueprint, which I patterned off of unix's way of doing it.
I dunno - some things unix doesn't get right in my opinion.  Any reason not do to <package>/<package-version> - so you have wordpress with your 15 million versions inside named wordpress-1.5 and wordpress-2.0 etc etc etc.

I know some things DO follow this pattern to some extent (stuff in the gtk stack do this with the includes directories - so you have /gtk/gtk-2.0 etc)

Not really that important - just something to ponder.

Arglegarble.

g

hehe - I just want to play with code... really.

Thanks,
Elizabeth M Smith

References