Nu

I love the idea here, but I’m not so keen on the need to use Ruby. Not that I dislike Ruby… I actually love Ruby. However, as a .NET package manager, it seems more than a little odd to be using something other than .NET, and some devs won’t be comfortable with this decision.

wekempf, I don’t think C# should get the 100% Java disease. I can’t see any compelling reason to require that everything used by .NET be written in .NET.

Besides, if someone uses Nu they might learn Ruby and that would be awesome.

If this gets traction and looks viable and stable I see no insurmountable reason as to why IronRuby & .NET 4 can’t execute these Ruby commands..? If one can’t or won’t install or use Matz’s Ruby. Dru?

Argh! It drives me crazy when people are so scared to use a tool that’s not .NET!

Why does it matter what platform the interpreter is running on? How is that in any way relevant? It’s one of the most bizarre case of “Oh well it makes me feel warm and fuzzy.”

AFAIC, Albacore is the only sane way to build .NET projects in the context of a CI system. Nu looks to be pretty badass as well.

It’s *sad* that I’m excited about something as simple as a package manager. What is wrong with our ecosystem?

Let me use the tool that let’s me get the job done. Quit giving me artificial technical limitations.

“I’m sorry, we can’t use command.com because it doesn’t run on .NET”

I love the idea Dru! I’ll play around with this later in my pet projects.

From a professional point, I would be more apt to using Nu at work if it wasn’t based on Ruby. I don’t have an aversion to Ruby, but I don’t enjoy making Ruby a dependency.

I would be much more apt to using it if the only dependency to run Nu was Nu its self.

CSC is written in C++. What’s Ruby written in C? Sacrebleu! Installing an unmanaged runtime is an issue a server team may be uncomfortable with. Why a developer?

This is the best example of why gems and nu (#nuproj) is awesome: http://pastie.org/1053673

Have you seen CoApp?

http://coapp.org/

Awesome!
Let me know if there’s something I can help with.

Playing with Nu, how do I know what packages are available? fluentnhibernate, log4net, etc.

Nice job! But your tool won’t become the ‘gems’ of .net because you still need to use gem to download things locally and even install Nu itself.
Nu seems more like a tool to “freeze” downloaded gems to your project.
Also I don’t know if the .NET community is used to upload projects as ruby gems.

While i am not fixed on the part that .NET tools should be developed only in .NET, i do think for something like this tool it should be in .NET. I have got Ruby installed on my system (for Watir), but i would seriously like to know how many desktop systems have Ruby installed out there. I do know that none of the team members i know have Ruby installed and all of them are .NET developers, so the moment we talk about using NU, they will stop trying it because it needs another runtime environment to be installed just for trying it. Since the target developer audience is .NET dev team, they would already be having that dependency and makes it easy for them to try and adopt. I think this will be the same of Java developers, ask them to try some tool which requires .NET 4, and they will avoid trying it in the first place.

FWIW, nu seems work fine with IronRuby. But I cant believe that a Ruby dependency would stop some from using a particular tool. FUD!

I also used nu with IronRuby (to feel that I am not departing from .net My experience after installing log4net, nunit etc. was that I was amazed by the simplicity of it and I think we should embrace things (ruby or not) which makes life easier for us. However, today I wanted to install elmah… and I didn’t knew which “gems” are available.

It’s one thing to install a tool, while it’s quite another to install a tool AND a runtime. That’s really the issue to me here. I could care less what language is used to implement the tool, but needing to install a runtime is something else. IronRuby doesn’t really change the picture much here from that perspective. Think about it. A tool such as Nu is really a fairly small thing, while the runtime for Ruby is not. If I’m not going to make use of that runtime outside of using it to run nu, that’s a mighty big waste. Being based on Ruby isn’t a show stopper for me, though I’m sure it will be for some, but if a nu alternative existed that didn’t depend on Ruby, I’d lean towards it.

I’ve been playing with Nu. Some things I don’t like about it today:

1. It’s unfortunate that packages are copied everywhere. It may not be feasable to not have a copy in every project that needs to reference the package, but the extra copy necessary due to using Gems as the package manager is unfortunate.

2. There should be a way to install of a project’s dependencies without having to know what they are. IOW, the project’s Spec file or something similar should be consulted so that a single nu command can be executed to install of the project’s dependencies.

3. Given 2, this stuff should be built into MSBuild, so that all a developer really needs to do is open the solution and build the project (assuming nu is already installed).

I really like where Nu is going, despite these complaints.