← Back to team overview

coapp-developers team mailing list archive

Re: What packages do you want to see?

 

PowerShell compatibility I think is pretty important. Luckily, that just means building nice libraries in .NET and making sure they work for PowerShell.

Basically, I'm thinking that the vast majority of the functionality on the client is bound up in some well-documented libraries, which would be usable from a variety of languages (.NET, native, PowerShell, etc.)

The UI and console apps would be written using that.

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 Kevin Moore
Sent: Friday, May 07, 2010 12:01 PM
To: coapp-developers@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Coapp-developers] What packages do you want to see?

May I extend your user story, Trent?

I got to the command line.
I type: coapp search ruby
I see: a list of ruby packages, including MRI, jRuby, IronRuby, etc. Each lists their latest version.
I type: coapp info ironruby
I see: A description of IronRuby. The available versions. A pointer to their source code on github.
I type: coapp install ironruby
I see: the installation prompt for the latest 'official' install of ironruby. I could also install older versions, or maybe beta/RC versions by specifying the --version flag

If this was all PowerShell compatible, it would be easy to do fun piping, filtering, etc of this output. It could also serve as a great basis for GUI tools.

On Thu, May 6, 2010 at 23:50, Trent Nelson <trent@xxxxxxxxxxxxx<mailto:trent@xxxxxxxxxxxxx>> wrote:

When a developer consumes a shared library (say, zlib), they consume the library by binding to a library that is identified by NAME, PLATFORM (x86/x64), VERSION and PUBLICKEYTOKEN ... the publicKeyToken is derived from the public key of the signing certificate.

So, if the publisher of zlib wants to publish one for VC9 and one for VC10 they have to have two authenticode certificates.  A bit of a pain, yes. But we can have the same version of the library installed for multiple compilers at the same time, and never have a conflict.

                Ahh!  That's a great solution!

Boost immediately comes to mind as a project that intrinsically supports being built in all sorts of ways (different compilers, optimisations, etc), so the publicKeyToken approach will work very well, IMO.

....and here's some thoughts out loud:

New user story:
I'm a Windows developer that wants to consume a bunch of CoApp projects.  I need to know all of their NAME, PLATFORM, VERSION and PUBLICKEYTOKEN details with minimal fuss (I don't want to go to each project's website and have to find the details individually).

I'd like to go to http://use.coapp.org, be presented with a Google-like minimalist page; search box and not much else.  I'd like to type in `python boost apr zlib libpng` and then be presented with search results that clearly depict the latest versions of each, with NAME/PLATFORM/VERSION and PUBLICKEYTOKEN details readily available.  For projects with multiple builds (i.e. Boost), and thus, multiple PUBLICKEYTOKENS, I want clear descriptions of which build does what.

                Follow on questions:
What do I do with this information when I get it?  Do I plug it into an XML file that gets consumed/processed by the CoApp tool chain?  If so, couldn't http://use.coapp.org just generate the XML file for me?  i.e. after I type in the projects I want, I get search results with check boxes; I tick the ones I want, press a 'Generate' button, and wallah, I get my XML file that describes all my dependencies.



_______________________________________________
Mailing list: https://launchpad.net/~coapp-developers
Post to     : coapp-developers@xxxxxxxxxxxxxxxxxxx<mailto:coapp-developers@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~coapp-developers
More help   : https://help.launchpad.net/ListHelp


Follow ups

References