Summary | Application should fail gracefully if prerequisites not installed |
Queue | Horde Framework Packages |
Queue Version | HEAD |
Type | Bug |
State | Not A Bug |
Priority | 1. Low |
Owners | |
Requester | php (at) ideacode (dot) com |
Created | 04/02/2008 (6315 days ago) |
Due | |
Updated | 04/09/2008 (6308 days ago) |
Assigned | |
Resolved | 04/09/2008 (6308 days ago) |
Github Issue Link | |
Github Pull Request | |
Milestone | |
Patch | No |
we'll be moving to an already-existing, more complete system in the
future - I don't think it makes sense to introduce a separate
dependency mechanism into Horde.
strategically sound. However, I would suggest -- and this may already
exist, I've just not gotten to that point in the manual -- that these
future plans be documented on an up-to-date roadmap so that
contributors understand your philosophy and direction. :)
State ⇒ Not A Bug
However, I'm going to stand by my (and Jan and Michael's) stance that
this isn't a bug. There is a philosophical difference in that I don't
think it's problematic that a user can cause a misconfigured or
improperly installed application to emit a fatal error. It's perhaps
not ideal, but it's not horrible. Fatal errors from a properly
installed and configured app are different of course.
My main reason for rejecting this, though, is that:
a. DIMP and MIMP are the only Horde applications that require any
other Horde application in this way, and the next version will fold
them both in to IMP, eliminating this situation.
b. PEAR already provides an extensive dependency mechanism, and it is
our goal to make Horde applications PEAR-installable in the future.
Given these two things - this is only true for two applications, and
we'll be moving to an already-existing, more complete system in the
future - I don't think it makes sense to introduce a separate
dependency mechanism into Horde.
Queue ⇒ Horde Framework Packages
documentation?
and the documentation should state the requirements, and both should
agree. My patch allows developers to codify the application
requirements in the conf.xml file. From that, Horde setup emits
warnings if some requirement isn't met, cluing the administrator that
there is a problem. Additionally, the documented requirements can be
parsed directly out of the conf.xml file so that both software and
documentation agree on the requirements, all the time.
IMP (or DIMP). DIMP _does_ require IMP. You keep making statements
that contradict one or both of these. Why?
You are right. I misunderstood Michael -- when I looked at his link, I
thought "that's Horde's (base) install file which is saying IMP is
required". When in fact it's DIMP's INSTALL file that says IMP is
required. So scratch all my rants related to Horde and IMP.
documentation?
IMP (or DIMP). DIMP _does_ require IMP. You keep making statements
that contradict one or both of these. Why?
documentation and ram it into the software, with the following added
to horde/conf.xml:
<requires>
<require app='imp' />
</requires>
So now user's errors are handled more gracefully and with less traffic
on the bugs list.
New Attachment: issue6559.diff
gracefully even if random files are deleted from it - which is along
the same lines as saying it should function without its requirements
installed - but there's, to be buzzwordy about it, low ROI there for
an open source project.
in the software. If IMP is a required module, then I should not be
able to run a Horde framework with only nag, mnemo, whups, and wicked.
But I can, which demonstrates a discrepancy between what the
documentation states are requirements and what the software states are
requirements. In the presence of such a discrepancy, the software's
view wins.
recognize the documentation states that IMP is a requirement, and
that's great, but the reality is that Horde (the collection) is a
complex organism, comprised of many different modules all with
differing requirements and implementation strategies, constrained by a
loose hegemony armed with guidelines designed to move everyone toward
a common goal. Recognizing that complexity, the purpose of this
request -- as low a priority as it may be -- is to provide a product
that remains strong in the face of users' errors.
And since I'm the type of guy to put my mouth where my bug reports
are, here's a patch. This patch adds "requirement" support to
configuration XML documents. The completely optional <requires>
container lists the mandatory applications that the given
configuration needs. DIMP, for example, might read:
<requires>
<require app="imp" />
<require extension="imap" />
</requires>
All requirements must be satisfied, or a warning is emitted on the
configuration page. In this case, both the imp application and the
PHP imap extension must be installed and loaded. The parser also
supports a version attribute for the requirement element, but I do not
immediately know how to get the version information consistently from
the registry or from an extension, so that's left as an exercise for
the reader.
gracefully even if random files are deleted from it - which is along
the same lines as saying it should function without its requirements
installed - but there's, to be buzzwordy about it, low ROI there for
an open source project.
And I'm sorry, but how is IMP not a requirement for DIMP?
IMP is the first prerequisite listed in the INSTALL file. We are not
going to waste CPU cycles on every page load checking for mandatory
prerequisites that are clearly indicated in the documentation.
that is most definitely a bug.
Second, IMP is not a prerequisite -- the documentation is wrong: you
can load the framework and run nag, mnemo, whups, and wicked without
any complaints from said applications.
Third, my suggestion was to prevent DIMP from be configured (under
Administration) if IMP is not first configured. That would have a
cost only at administrative setup time, which is a most rare use case.
Finally, I strongly disagree that this ticket should be closed as "Not a Bug".
State ⇒ Not A Bug
IMP is the first prerequisite listed in the INSTALL file. We are not
going to waste CPU cycles on every page load checking for mandatory
prerequisites that are clearly indicated in the documentation.
Priority ⇒ 1. Low
State ⇒ Unconfirmed
Patch ⇒ No
Milestone ⇒
Summary ⇒ DIMP should fail gracefully if IMP not installed
Type ⇒ Bug
Queue ⇒ DIMP
operational Horde framework without IMP allows you to configure DIMP,
but when clicking Options for DIMP generates a PHP fatal error:
Fatal error: require_once() [function.require]: Failed opening
required
'/home/bishop/www/staging/horde/config/../imp/lib/Notification/Listener/status.php' (include_path='.:/usr/local/lib/php/') in /home/bishop/www/staging/horde/dimp/lib/Notification/Listener/status.php on line
3
DIMP should gracefully degrade in this situation, perhaps by providing
a nice message stating that IMP is not installed. Better, IMO, would
be to prevent DIMP configuration absent a configured IMP install.