Should applications be packages?

[Maarten Balliauw]

Interesting discussion: should applications be packages?

https://github.com/aspnet/KRuntime/issues/766

[Anton Chelnokov]

Yes, but...

Applications must not be nupkg.

=)

[Alex Papadimoulis]

> should applications be packages?

 

So, should we take a mostly hacked-together platform, and then hack a modification on top of it to do something completely different? Why yes, of course!

 

You see, the beauty about a zip- and xml-based file format is that you can put anything in it... even more zip and xml files!

 

So, I propose we also consider a way to leverage NuGet as a storage/retrieval mechanisms for cat pictures -- the higher the version number, the more awwww the picture. Thinking further... we could also store our favorite MP3 files (an "album" package could just take dependencies on multiple "song" packages)... and also, we could have a separate feed for various recipes of curry. Just think of all the non-existent problems we can engineer shitty solutions for!

 

Speaking of which, I'll start specing out MeowGet now. Who's with me?

[Anton Chelnokov]

I want too!
but i will pack-in wikipedia and lang-to-lang dictionaries!

воскресенье, 26 октября 2014 г., 10:50:34 UTC+4 пользователь Alex Papadimoulis написал:

[Anton Chelnokov]

Did some one will create secure decentralized messanger wroks over nuget?

[Maarten Balliauw]

Not a cat person, so MeowGet is all yours :-) And I feel apps in packages too. To quote a website you may know: "Deploy Your .NET Applications with ProGet

ProGet's deploy features can be used to deploy .NET Windows Services and ASP.NET applications by packaging applications into Chocolatey packages and running them on a target server automatically with PowerShell remoting. Learn how..."

All puns and jokes aside, NuGet as a protocol is a perfect fit. A zip with some xml can ship anything. More importantly, there is an id and meaningful versioning scheme that can be leveraged to upgrade, downgrade, ... The best answer to the question if app packages should exist is already out there! Chocolatey ships powershell scripts. Octopus and ProGet ship... Apps! Orchard uses nuget for CMS modules. R# distributes app plugins with it. I've seen installers use nuget under the cover.

NuGet the implementation may be broken, but NuGet the protocol is an awesome thing. Implementation can be fixed.

[Jeff Handley]

Thank you Maarten, well said.

NuGet was never meant to be a platform.  It was a package manager for Visual Studio.  But it is clear that other domains want it to be a platform.  As we transform the design and implementation, we must consider that it will get used as a platform.

---

From: Maarten Balliauw
Sent: ‎10/‎26/‎2014 2:05 AM
To: nuget-e...@googlegroups.com
Subject: [nuget-ecosystem] Re: Should applications be packages?

--
You received this message because you are subscribed to the Google Groups "NuGet Ecosystem" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nuget-ecosyst...@googlegroups.com.
To post to this group, send email to nuget-e...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Anton Chelnokov]

Yes application as packages is good. but...

 > A zip with some xml can ship anything.

nuget is so java =)

Yes.

Main trouble is powershell. it not crossplatform. and...

repeate, i do not wan to run any shell script automatically!

It want confirm any action todo! see for android app permissions.
I think it would be standalone application nuget with !manual! updates.

I think there would be posibility to install plugins:

- pack for IIS
- pack for any other and other...

one action - one plugin - one public class

i want to know what package can do and what they do!

I want to block any action.

i want not see readme.txt any time i install package. And some packages install readme to project!

i want not to confirm licenses on update if them not changed!

its all can implement with plugin system, but we have not it!

And there would by crosplatform script language, not powershell! 

i think what python or groovy will be best choise. I think groovy better choise. Does python good work on windows?

of course only sematic of groovy i do not say to depend nuget on java and groovy =)

but familiar syntax better then anything new. just see for c and all other c-like languages)

And nuget 3 cannot give it to me. you must throw it out and start with a clean slate...

I want to have pure system for package management. But bulding of packages is depends on builder. And it good what roslyn is OSS.
I think it`s only time required to implement good package system like bower and other.

I hate you, nuget team, to download nuget.exe any time i enable restore on build... why u cannot use nuget integrated in plugin? is it possible?

My vision  is:
- standalone (do not depends on VS plugin) - you install it manual!!! remeber for $PATH!

- crossplatform - no comments...

- extendable with plugins

- can block any actions or install plugins for custom actions.

And more, any action is plugin! of course some plugins will inslude with installation, but dangerous plugins will be disabled! Nothing to log on fs, Win Registry or download anything from web by default!!!

Ofcourse it can be need for some corporative solutions, but not for everyone!

- repositories of plugins.

- pure proocol without OData. i donot see how works apiv3, but what i saw is bad...

[http://preview.nuget.org/ver3-ctp1/islatest/segment_index.json](http://preview.nuget.org/ver3-ctp1/islatest/segment_index.json) - its very, very, very bad! 

i just want 

http://preview.nuget.org/api/3/packages?q=newtonsoft.json&platforms=$json

$json is [

{arch: 'x64', kre: 'mono-3.10'},

{arch: 'x64', kre: 'netp45'},//is .net portable version is correct???

...

]

it`s simple, and returns any founded packages (PackageRegistration) are satisfyed all constrains

http://preview.nuget.org/api/3/packages?packageId=newtonsoft.json&platforms=$json

it returns any founded package versions (Package) are satisfyed all constrains

of course nuget must not concentrate only for .net packages, i think it will good package anythink we want.

If i want to package virtals machines in .nupkg, i will do it!

but i think we must not concurent with docker... =)

there is too many troubles.

You think narrowly.

nobody want v2-v3 compatibility, and you broke it with SemanticVersion2...)
so i donot understand, why u stilladd package.nuspec?

of cource different files for different target is good.

so i will not want to see install scripts in nuget.json file =)
but any information will not be repeated!

oh, so many was writen...

I'm late for work. i will be back at Grinwich6pm. 

Prepare ur questions and suggestions =)

[Anton Chelnokov]

I propose to design next better nuget now! 

Api v2 is pretty good, api v3 some better, but not best what we can create!

First it require what it will do, and next how.

I think we must  glances with one eye on project 'http://fsprojects.github.io/Paket/'

[Anton Chelnokov]

And i think, it will be good use one system to packages installation and build system.
So we have(need):
- package format for everything

- package distributing system - nugetGallery

- standalone build system with plugins - any action is plugin, and i must can configure permitted plugins global or for single solution/project. //repeate, i want to block any webrequest or fs-WinRegistry writings...

package installing implement as plugins. 

plugin system is

plugin -> handler -> action(params)

Any action can dependends on ther actions, depedends only action-to-action, nothing for plugin or target
Plugin and Handler names can contains dots, action cannot.

for example:

nuget -> package -> {search, download, publish} - dependendsOn {nuget-Server-Connect, nuget-server-request}

nuget -> project -> {InstallPackage, UpdatePackage, RemovePackage} - dependensOn  {nuget-package-search, nuget-server-request}

[Alex Papadimoulis]

Oh, right, so I forgot ProGet did that! To be fair, we're more leveraging Chocolately... but...

Dependency management is a somewhat complicated problem, but it's especially a difficult one to solve in .NET (as Jeff described in his post) due to all the varying frameworks, GAC rubbish, Javascript files, native stuff, etc. Java, Ruby, etc, don't have these problems, and NuGet never quite got it right (but hopefully will in v3).

You know what doesn't have any of these problems? Applications.

If the goal is to make NuGet a competent .NET dependency management platform -- which, as far as I can tell, that's the goal now -- then trying to also generalize it into a "platform that can ship anything!" is going to make it even worse. You can't have something that solves a problem in both a highly specific and a highly generalized manner. See: everything, ever.

A generalized listing of searchable and versioned packages is a trivial problem to solve. Using NuGet to get that "for free" is like using a car just to get the radio "for free".

The concept of Chocolately is fine, clearly something the market wants, but the absolute worst part of Chocolately is that it's hacked on top of NuGet. So it inherits all of NuGet's issues, plus the "hacked on top of" issues, plus it's own set of problems as a growing platform.  It's also seriously difficult to add needed-features, like "will this package work on my version of Windows?". I shudder to think of the hacks needed for what should be a simple feature like that. We know this first hand because ProGet Deploy helps build and automate Chocolatey package deployment... which was impossible to do without a whole set of clever hacks on our part, thanks to the behind-the-scenes NuGet usage. 

I have no idea how Orchard does it's modules thing, but my guess is that the worst part about it is NuGet. Anything that uses NuGet behind the scenes to do anything other than .NET dependency management would have been better off solving the problem in a different manner.

Don't get me wrong, it's not NuGet's fault that it doesn't work in an unsupported manner.I don't blame Craftsman when their hammer does a poor job at nailing in a screw.

Make NuGet the best damn phillips #8 screwdriver possible.  We don't need another "tool that can do anything."

Microsoft already has one of those. It's pretty awesome. It's called C#.