Idempotency – include everything necessary to allow the gem to be
rebuilt and regemified.
Repackagers – make it easier for repackagers by including the
necessary package-time dependencies.
Developers – make it easier for developers by including the
dependencies required to run, say, rake test.
RubyGems – make hoe a run-time dependency until RubyGems supports
develop-time dependencies.
seattle.rb – help up their download stats on rubyforge.
Against:
Users – don’t waste the time and space of people who aren’t in the
above list.
Sysadmins – don’t add another to the list of software they have to
audit.
Developers – don’t insult their intelligence. They’re doing something
outside the scope of a typical user, and know how to read a README and
gem install hoe.
RubyGems – don’t abuse the “run-time dependency” list just to get
around the lack of a develop-time one.
Did I miss anything? Now, all I think is necessary is a web poll
somewhere, and the dead horse will have been thoroughly beaten.
(Actually I think that the test-driven philosophy should encourage
developers to think of the tests as just part of the product and
package them as such whenever it is reasonably possible. But there
are bound to be occasions when this is not practical.)
Given your last paragraph, why would idempotency dependencies be any
different than dependencies necessary to run the tests? If I were to
switch all of my unit tests to rspec, would it be appropriate to mark
my gem as depending on rspec? After all, only the people who are going
to run the tests will need it, just as only people who are going to
interact with the gem on a meta-level will need hoe.
I’d much rather not have to manually go through each gem, figure out
what it needs so that I can run its tests, store that somehow (since
it’s not in the spec), install the dependencies since they aren’t
already, and all that to just automatically run tests for the gems.
Maybe a simple convention is all that’s needed. (Echoing myself in
another thread.) If the full test set for “foo” is too cumbersome,
release it as “foo-test”. It should be easy to write a script that
installs “foo-test” for every installed gem “foo”.
(Actually I think that the test-driven philosophy should encourage
developers to think of the tests as just part of the product and
package them as such whenever it is reasonably possible. But there
are bound to be occasions when this is not practical.)
Users – don’t waste the time and space of people who aren’t in
the above list.
+1 . Surely the point of a packaging system is to serve people who
just want to “wash and go”. Why compromise that because someone else
has a problem? “Do one thing, do it well.”
Sysadmins – don’t add another to the list of software they have
to audit.
+1 . (I’m a sysadmin.)
Developers – don’t insult their intelligence. They’re doing
something outside the scope of a typical user, and know how to read
a README and gem install hoe.
+1 . To make it even easier, why not have a “foo” gem for users and a
“foo-dev” gem for developers? Maybe a simple packaging convention is
good enough.
RubyGems – don’t abuse the “run-time dependency” list just to get
around the lack of a develop-time one.
+1 . Fix the real problem, don’t break something else trying to paper
it over.
The problem I see with that is similar to removing programs in Windows.
Often, it says something to the effect of “it appears no programs are
using the xxxxxx.dll file. Do you want to remove that too?” Well, how
would I know? I don’t know what it does. I think any optional
dependencies would need a good description of what it is and why you
would want it. Something better than a small phrase, anyway.
Default: no prompt, no install
-Y: no prompt, install
–optional-dependencies: prompt
A way to install the optional dependencies for an already-installed
gem would be great, too. I’m not thinking of a great syntax off the
top of my head, though.
So if I were to spend this weekend getting optional/developer-time
dependencies into RubyGems, would people want optional dependencies to
always be prompted, only prompted when a flag is given, or never
prompted?
I suggest looking at Debian’s way of doing it. They have “recommends”
and “suggests” dependencies. (after all, apt is probably the mother of
dependency management systems, and gem is intellectually based on
apt-get)
The “aptitude” utility thus has “–with-suggests” and
“–with-recommends”, as well as “–without-…”.
Of course, debian also has “build-dependencies” which aren’t installed
with “apt-get install”, but “apt-get build-dep”. So a fusion of these
two concepts should do the trick.
FWIW, I’d much appreciate adding such a notion to gem.
The problem I see with that is similar to removing programs in Windows.
… I think any optional
dependencies would need a good description of what it is and why you
would want it. Something better than a small phrase, anyway.
Ok, so we do the same thing for uninstalls:
I think the uninstall thing was just an analogy. I believe he was
referring to those types of messages being cryptic in general. “Test
suite only? Why yes, I write unit tests! I guess I have to get rspec,
too.” Or say you’re installing some logger package… “win32console (for
color messages)? What if I want some in color and some not?”
Meh, those are bad examples. For that matter, I’m not positive a good
example exists. Meh, whatever. I do remember that a Gentoo USE
variable of (say) +SSL meant many, many, many different things depending
on what you were installing, but that’s neither here nor there.
Yes, it’s a great idea … but … you are going to get very biased
statistics, because many Ruby users will be prohibited, either
electronically or by organizational policy, from uploading such
information.
Our place is medium-paranoid, and after doing a “tattle report”,
I was comfortable doing a “tattle”. So far, our IT Security folks
haven’t rained down upon me like the CDA in Monsters Inc.
But the question is would the hoe developers use this? They seem
fairly stuck on this whole idempotentence kick.
I’m pretty sure that one of the messages in the last ~90 or so
indicated that were optional dependencies available, hoe would use it.
It wouldn’t help for anyone who already has hoe-generated gems, of
course.
You may not realize it, but you want idempotence, too. One of the
things that can be done with an idempotent gem is that you can
validate a gem on a development server, and then you can repackage and
redeploy that gem on a production server without redownloading it from
the original site.
There’s still some work to be done on RubyGems to make this truly
possible without hacks (local installs don’t really handle
dependencies well, plus a few other things), but without idempotence,
you’re not guaranteed to have everything you need to do that.
Seriously, worth a chat on rubygems-developers, I think.
Hoe hasn’t finished evolving yet. At present a new Hoe feature can
be released less than ten minutes from commit time. With RubyGems
that takes a month (so far).
