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).
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.
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.
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?
–
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)
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.
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.
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.
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.
–
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)
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?
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)
