[Mono-list] SPAM-LOW: Re: NUnit Version - Upgrade soon?

[Charlie Poole]

Good - I felt I wasn't expressing what I wanted.

First, I should say that I don't have the expertise (yet)
in Linux that I have in other platforms. So I may still
have some misconceptions. I expect this to change within
the next few months. I'm getting a new system to dedicate
to developing NUnit on Linux, rather using Windows and 
only running tests on virtual machines. But for now,
my ideas are limited by my experience.

ANYWAY... it seems reasonable for me to have a private 
copy of NUnit hidden in /usr/lib/mono for internal use.
The natural place to install an NUnit application would
seem to be /usr/lib/nunit or (if we support multiple
concurrent versions) /usr/lib/nunit-x.x.

The problem comes with commands, which are all in the
/usr/bin directory and have play well together. This
can be equally true on Windows, except that Windows 
developers seem less likely to use the command shell.
It is used in nightly build scripts, but in that case
an awkward syntax is not a problem. Anyway, most Windows
teams don't actually "install" nunit, but copy it to
their development tree.

One approach is to use command scripts like nunit-x.x
for each version of NUnit installed, with a master
script that points to the latest. That's how I do it
on my own (Windows) systems.

For Linux, I think it would be preferable for the
nunit script to reference a conf file. The last 
installed nunit package could update the current
version and subordinate scripts might not even
be necessary.

One reason normal users need to have side by side
installs of different NUnit versions is that they
need to try out all their existing tests on the
new version before committing to it. In fact, this
is a weakness in NUnit and - even more - in the
management of packaging in Windows itself. It could
be that this will become very simple once we have
packages that install and revert easily. That's
what I'm hoping anyway. If a user did not need
to change any build scripts to go to a new version
of NUnit, then it would be only developers of 
NUnit who need to worry about multiple installs
and that can be dealt with using different roots.

I'm looking for folks who will help with making 
this work smoothly and seamlessly, btw. :-)

Charlie



> -----Original Message-----
> From: Atsushi Eno [mailto:atsushi at ximian.com] 
> Sent: Friday, November 28, 2008 1:39 AM
> To: Charlie Poole
> Cc: mono-list at lists.ximian.com
> Subject: Re: [Mono-list] SPAM-LOW: Re: NUnit Version - Upgrade soon?
> 
> Hi Charlie,
> 
> Ahh, I get your point, that is a visible problem. Since I'm 
> just a volunteer to upgrade the version here, I am not at the 
> position to decide what we should include in our package.
> nunit-console shell script is not actually used to build mono 
> and mcs (instead we use mono-wrapper and nunit-console.exe
> directly) and this script can be removed if we just think 
> about mono and mcs.
> When it comes to other modules, for example we use 
> nunit-console directly in Olive. So I assume we still sort of 
> need a shell script.
> 
> I assume we could rename nunit-console to mono-nunit-console 
> or whatever, to explicitly indicate that it is for mono internals.
> 
> Is this the only concern, or is it just an example? :)
> 
> Atsushi Eno
> 
> 
> Charlie Poole wrote:
> > Hi Atsushi,
> > 
> >>> If you want to attract folks to Mono, then I think it's
> >> important not
> >>> to confuse them. :-)
> >> If there's reasonable reason people get confused because of my 
> >> interpretation or effort on upgrading nunit version, then I feel 
> >> sorry ;)
> > 
> > Even though this thread started as a result of your 
> upgrade, I don't 
> > think the upgrade causes the confusion. I think it already 
> existed for 
> > people who are moving from the Windows world to Linux+Mono and your 
> > upgrade just continues in the same way it has always been.
> > 
> > Specifically, if I type "nunit-console" I get the version 
> you install 
> > with NUnit. I can't change that without over-writing a file that is 
> > part of mono. But installs should not overwrite files 
> created by other 
> > packages, so I have to create a comand like "nunit-console-25"
> > and the old version remains the default when it makes more 
> sense for 
> > the new version to be the default. Of course, an individual 
> user can 
> > choose to rename these files and deal with package problems 
> manually, 
> > but my install can't (shouldn't) make such a decision.
> > 
> > Can you see the problem?
> > 
> > Charlie
> > 
> >> Atsushi Eno
> >>
> > 
> > 
> > 
> > _______________________________________________
> > Mono-list maillist  -  Mono-list at lists.ximian.com 
> > http://lists.ximian.com/mailman/listinfo/mono-list
> > 
> 
>