Modules and version determination


(Berger, Daniel) #1

Kirk, it sounds like you’ve thought this out a bit. Any chance of
publishing something? It sounds like a good idea. Once you have something
out there, it’s a small step to write a script that generates some stub
documentation and methods automatically when you want to create a new
module, ala Perl’s h2xs (ok, slightly different, but hopefully you get the
point).

Anyone care to second my nomination? :slight_smile:

Regards,

Dan

···

-----Original Message-----
From: Kirk Haines [mailto:khaines@enigo.com]
Sent: Wednesday, June 12, 2002 3:25 PM
To: ruby-talk@ruby-lang.org
Subject: Re: Modules and version determination

The two ideas are somewhat orthogonal. RubyVersion was
really just a
way of representing the version, so it can easily be
compared to other
versions. Kirk’s mixin attaches the version to the module,
and could
easily store the version as a Version object instead of as
a string or
a float.

Yes, quite easily. Right now it accept the version as a
string, on the
assumption that there are few assumptions about version
numbers. I could
easily change it to store that version, as you say, in a
Version object.

Kirk Haines


(Dossy) #2

Another thing that is important to track is module dependencies.
Say, if I write a module Foo that depends on REXML, I should be
able to specify that in the module metadata as well.

Perhaps we can start gathering some requirements on the wiki
and once there’s consensus, put together a simple implementation.
Then, if it’s worthy, it’ll take hold and people will use it.
Otherwise, it’ll get abandoned and that’ll tell us something
about it’s necessity.

I personally would love to do:

ruby -raa upgrade REXML-stable

and have it go out, check to see if there’s a newer version of
REXML out, and install it for me.

– Dossy

···

On 2002.06.13, Berger, Daniel djberge@qwest.com wrote:

Kirk, it sounds like you’ve thought this out a bit. Any chance of
publishing something? It sounds like a good idea. Once you have something
out there, it’s a small step to write a script that generates some stub
documentation and methods automatically when you want to create a new
module, ala Perl’s h2xs (ok, slightly different, but hopefully you get the
point).

Anyone care to second my nomination? :slight_smile:


Dossy Shiobara mail: dossy@panoptic.com
Panoptic Computer Network web: http://www.panoptic.com/
“He realized the fastest way to change is to laugh at your own
folly – then you can let go and quickly move on.” (p. 70)


(Kirk Haines) #3

Another thing that is important to track is module dependencies.
Say, if I write a module Foo that depends on REXML, I should be
able to specify that in the module metadata as well.

Perhaps we can start gathering some requirements on the wiki
and once there’s consensus, put together a simple implementation.
Then, if it’s worthy, it’ll take hold and people will use it.
Otherwise, it’ll get abandoned and that’ll tell us something
about it’s necessity.

I’ll volunteer to take my current module and mutate it to fit this
set of requirements.

I personally would love to do:

ruby -raa upgrade REXML-stable

That would be very cool, indeed.

Kirk Haines


(Massimiliano Mirra) #4

You can already do the latter with rpkg/rapt:

rapt install rdoc

It is checked if a newer version is available and it is installed
according to the user configuration (e.g. all the docs here, all the
tests there, all the binaries here…). You can remove packages,
search them, query for description, version, maintainer address,
etc. as well.

Versioning information is supported, dependence handling not yet.
Also, there are only a dozen packages online. The entire process of
packaging takes about 10 minutes and is explained in the tutorial,
uploads are welcome.

The whole thing is downloadable from
http://www.allruby.com/rpkg/rpkg-0.3.3.tar.gz, documentation is
English and Japanese (courtesy dellin).

Massimiliano

···

On Thu, Jun 13, 2002 at 10:53:16PM +0900, Dossy wrote:

Perhaps we can start gathering some requirements on the wiki
and once there’s consensus, put together a simple implementation.
Then, if it’s worthy, it’ll take hold and people will use it.
Otherwise, it’ll get abandoned and that’ll tell us something
about it’s necessity.

I personally would love to do:

ruby -raa upgrade REXML-stable

and have it go out, check to see if there’s a newer version of
REXML out, and install it for me.


(Dossy) #5

So, if module authors would just distribute them as rpkg/rapt
packages, life would be good? :slight_smile:

This is great news. Are there reasons why all modules shouldn’t
go this route?

– Dossy

···

On 2002.06.14, Massimiliano Mirra list@chromatic-harp.com wrote:

I personally would love to do:

ruby -raa upgrade REXML-stable

and have it go out, check to see if there’s a newer version of
REXML out, and install it for me.

You can already do the latter with rpkg/rapt:

rapt install rdoc

It is checked if a newer version is available and it is installed
according to the user configuration (e.g. all the docs here, all the
tests there, all the binaries here…). You can remove packages,
search them, query for description, version, maintainer address,
etc. as well.

Versioning information is supported, dependence handling not yet.
Also, there are only a dozen packages online. The entire process of
packaging takes about 10 minutes and is explained in the tutorial,
uploads are welcome.

The whole thing is downloadable from
http://www.allruby.com/rpkg/rpkg-0.3.3.tar.gz, documentation is
English and Japanese (courtesy dellin).

Massimiliano


Dossy Shiobara mail: dossy@panoptic.com
Panoptic Computer Network web: http://www.panoptic.com/
“He realized the fastest way to change is to laugh at your own
folly – then you can let go and quickly move on.” (p. 70)


(Massimiliano Mirra) #6
rapt install rdoc

So, if module authors would just distribute them as rpkg/rapt
packages, life would be good? :slight_smile:

I’d be crazy to work on the whole damn thing and not think so. :slight_smile:

This is great news. Are there reasons why all modules shouldn’t
go this route?

Honestly I don’t know, and would love to hear criticism and advice,
however I suspect that my microscopic marketing skills do play some
part in it.

Massimiliano

···

On Fri, Jun 14, 2002 at 11:09:57PM +0900, Dossy wrote:


(Dossy) #7

Is there a reliable rpkg/rapt server? If the issue is re-packaging
everyone’s Ruby modules on RAA into rpkg format, perhaps we can get
this done through volunteers.

I assume rpkg/rapt are native Ruby programs themselves?

– Dossy

···

On 2002.06.15, Massimiliano Mirra list@chromatic-harp.com wrote:

This is great news. Are there reasons why all modules shouldn’t
go this route?

Honestly I don’t know, and would love to hear criticism and advice,
however I suspect that my microscopic marketing skills do play some
part in it.


Dossy Shiobara mail: dossy@panoptic.com
Panoptic Computer Network web: http://www.panoptic.com/
“He realized the fastest way to change is to laugh at your own
folly – then you can let go and quickly move on.” (p. 70)


(Massimiliano Mirra) #8

Is there a reliable rpkg/rapt server?

Curt Hibbs kindly provided the space where the current .rpk packages
are kept, http://www.allruby.com. Never had a problem with it.

I assume rpkg/rapt are native Ruby programs themselves?

Yes, they are. They are also self-contained, the only external
dependency is zlib which will be in the next Ruby standard
distribution.

Massimiliano

···

On Sat, Jun 15, 2002 at 09:37:41AM +0900, Dossy wrote: