The Common Opensource Application Publishing Platform (CoApp)

re: The Common Opensource Application Publishing Platform (CoApp)

Beni Paskin-Cherniavsky — Tue, 13 Apr 2010 14:17:16 GMT

For Python on windows, the closest to Right Thing distro currently is http://pythonxy.com - they provide independent modules as seperate installers (though EXE and not MSI), but you must install dependencies manually; if you opt to use their big install, you also get all dependencies and updates automatically.

I guess they'd be happy to use CoApp instead for dependencies.

Another projects that might make a lot of sense for early conversion to CoApp is Cygwin, which also currently uses its own dependency-managing installer.

Because like it or not, software originally developed for linux will have a unixish build process, and Cygwin/Mingw provide the easiest path to replicate such build on windows.

re: The Common Opensource Application Publishing Platform (CoApp)

Dulob — Mon, 12 Apr 2010 23:55:49 GMT

How about attacks and viruses. Windows has been the maintarget for attacks and Viruses... I think this project will open opportunity get infected with new kind of trojans and virues.

re: The Common Opensource Application Publishing Platform (CoApp)

Steve Walker — Mon, 12 Apr 2010 19:24:41 GMT

I can't help feeling that if this was worth doing it wouldn't be necessary. After 10 years or so trying to get Windows admins/devs to consider open source solutions my main experience is that the prevailing culture on Windows is not the 'do-it-yourself' mentality that saw the creation of the OSS you're aiming at but more a 'I'll-pay-someone-to-do-it-for-me' culture. Creating a nice point and click repository of Linux ports might help get that software onto more Windows machines but would do

nothing to promote the open-source ideal and help foster a healthy open-software community on Windows. Frankly, if the future of open-source on Windows is nothing more than a collection of ill-fitting Linux ports then Windows open source is dead and we

may as well admit it.

Also, I'm a little puzzled at your choice of Apache and Python - these already have excellent Windows versions which install as easily as any Windows apps I've used. As for PHP given its threading issues and the need to restrict it to a FastCGI host I'd say this is a good example of why some Linux apps will never work as well on Windows as on Linux and the ultimate pointlessness of looking to port them for anything other than development use.

re: The Common Opensource Application Publishing Platform (CoApp)

David Fraser — Mon, 12 Apr 2010 18:33:00 GMT

Yay, at last! I've been saying somebody should do this for years...

Some of my perspective:

* Yay for using MSI - presumably you include some kind of extra information in MSI files about their dependencies?

* As somebody mentioned above, it would be great it you supported an opensource toolchain as well as the Microsoft one

* Even if you're using the Microsoft toolchain (and I understand the desire to have people using IDEs be happy), please make it so auto-building a source package is a single-step operation that doesn't have to involve opening the IDE - this should be doable with the Microsoft make tools. Essentially you want to be able to say "get me the dependencies of this package, run the build, give me the output" without lots of clicking.

* What's your strategy for dependencies? Although the target platform's totally different, apt-get and yum solve lots of finicky dependency problems - I think re-writing your own system for finding and deploying packages and resolving dependency issues is going to be more work than building on top of what's already there

* For people building commercial software on top of open source software, it would be great to be able to have additional repositories that can depend on libraries in the open ones

re: The Common Opensource Application Publishing Platform (CoApp)

Danny Staple — Sun, 11 Apr 2010 19:57:13 GMT

Hmm - couldn't stop myself. Windows will not be ready until somebody like Garrett does this - I think full steam ahead.

I understand the distinction you are making between binary package managers like Apt/yum and source/build packaging like portage, however, for this project it looks like it will be trying to bring both things together, which I for one think is great.

Having been a Gentoo user, as well as Suse and Ubuntu (yes also Redhat and Debian), I am familiar with them, and always would have loved to combine some of the strengths of both types of systems.

re: The Common Opensource Application Publishing Platform (CoApp)

Adriano — Sun, 11 Apr 2010 15:26:04 GMT

Why should the linux community should put that large enforces to reinvent the well as square to run every free software on Windows machines? Sound like working for free for a multi billion dollars company that don't like us.

Some important softwares like Apache, PHP, etc must be windows compatible to gain share market and grow, but mostly nix softwares creators don't have that will/needle.

IMHO the Microsoft should respect and deep collaborate with the community first to gain admiration. The opensource works because we help and respect each other.

re: The Common Opensource Application Publishing Platform (CoApp)

Dungeon Dave — Sun, 11 Apr 2010 08:55:22 GMT

Interesting article, but I think you have a number of problems to overcome, and it's not clear to me if you're trying to create a standardised compiling mechanism (like portage) or a way of standardising the installation of open-source apps (apt/yum).

Either way, I feel that Windows isn't quite ready for it - with the way directory structures exist with Windows and the challenge of getting vendors onboard.

Good luck with it, though. The concepts themselves are sound - I'd like to see this succeed.

re: The Common Opensource Application Publishing Platform (CoApp)

Danny Staple — Sun, 11 Apr 2010 08:51:06 GMT

Hi Garrett,

This sounds like a great idea. Lets hope it works out!

Got a couple of questions for you:

Will you also make sure it is non-admin freindly? That is that software that is not say a webserver, but is more user space, will not hassle the user for admin rights unnecessarily with UAC?

If it works with VC, can you also make sure it is VC express compatible for hobbyists? It's one thing having an employer fork out for VS at work, but another doing so at home, especially when GCC + Eclipse is free.

One other thing worth noting is that the usual add/remove programs dialogue in Windows, while the de-facto way of removing non system stuff, is one big flat list, which when many libraries and tools with dependencies are installed will look ugly. Perhaps one idea is to have in the dialogue a single CoApp bundle, with a "Change" button that launches a wizard that groups up packages (as do most Linux package managers), and handles dependencies. Heck - this could be used to add as well as remove packages if linked with update sources in a similar way to portage/apt/yum.

Danny

re: The Common Opensource Application Publishing Platform (CoApp)

Laete a.k.a Drak[X] — Sun, 11 Apr 2010 07:20:45 GMT

Hmmmm.....

MS Win-Get !?!?!?!?

Link: http://windows-get.sourceforge.net/

"win-get is an automated install system and software repository for Microsoft Windows written in pascal (for the command line client) and php for the online repository. The ideas for its creation come from apt-get and other related tools for the *nix platforms.

The system works by connecting to a link repository. Finding an application and downloading it from the stored link using wget.exe . Then performing the installation routine (silent or standard). And finnally deleting the install file."

re: The Common Opensource Application Publishing Platform (CoApp)

Garrett Serack, MSFT — Sat, 10 Apr 2010 20:21:41 GMT

@Vladislav --

I'm not building a new build system. I'm using Visual Studio (MSBuild)

What I am building is tools to transform *whatever* existing build process to one that Visual Studio supports.

I spoke to Bill Hoffman (Kitware) *YESTERDAY* about this very thing.

Now, luckily, the tool that actually generates the .vcxproj/.sln files is completely pluggable, meaning that with very little effort, it could churn out CMake scripts.

Bill and I are going to sync up again over the next few weeks to see where we can accomplish this.