Re: [Koha-devel] [Koha-patches] [PATCH] Bug 2176: adding SMS::Send to list of dependencies
Warning: Reply-To set to koha-devel. "Andrew Moore" <andrew.moore@liblime.com> wrote:
I guess it should be optional. Good point. If it's an optional dependency, how should I indicate that? Should I leave it out of Makefile.PL altogether?
I know no good way to indicate optional modules in Makefile.PL. Three choices that I think are better than total omission:- 1. put it in as a comment and POD string; 2. put it in as something like %CURRENT_PM like spamassassin does http://spamassassin.apache.org/full/3.0.x/dist/Makefile.PL 3. switch on META.yml generation and add a recommends line http://module-build.sourceforge.net/META-spec.html Which do people prefer? I'd lean towards doing (1 or 2) and 3.
Why does this patch covertly reindent everything?
I didn't intend for it to be covert. [...]
OK. Please try to mention these things in comments. It'd be a bit of a pain to cherry-pick a patch described as "adding SMS::Send ..." and have the dep's rewritten without warning.
I'd really like to be able to use perltidy to make the code that I edit and contribute more readable. Is there a particular indentation style that you think would be good to use on code that I change in Koha? I couldn't find much about this on the wiki.
If my notes from 1.9 are accurate, we used to use perltidy -bar -ce -pt=2 -vt=2 -en=4 which is almost what is in the perlstyle manual, except cuddled elses. However, it's not been enforced much and "more readable" depends on what you're using to read it... The wiki really isn't in good shape and I find it too much of a pain to edit. Searching the mailing list and IRC is usually more useful. Should we create a HACKING file (which is what I think GNU software calls the file) with the above sort of info in it? Regards, -- MJ Ray (slef) Webmaster for hire, statistician and online shop builder for a small worker cooperative http://www.ttllp.co.uk/ http://mjr.towers.org.uk/ (Notice http://mjr.towers.org.uk/email.html) tel:+44-844-4437-237 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
On Mon, Jun 23, 2008 at 5:18 AM, MJ Ray <mjr@phonecoop.coop> wrote:
Warning: Reply-To set to koha-devel.
"Andrew Moore" <andrew.moore@liblime.com> wrote:
I guess it should be optional. Good point. If it's an optional dependency, how should I indicate that? Should I leave it out of Makefile.PL altogether?
I know no good way to indicate optional modules in Makefile.PL. Three choices that I think are better than total omission:-
1. put it in as a comment and POD string;
2. put it in as something like %CURRENT_PM like spamassassin does http://spamassassin.apache.org/full/3.0.x/dist/Makefile.PL
3. switch on META.yml generation and add a recommends line http://module-build.sourceforge.net/META-spec.html
Which do people prefer? I'd lean towards doing (1 or 2) and 3. I prefer that all potential dependencies be clearly stated in the Makefile.PL, whether for optional features or not ... too many people installing Koha will perceive an after-the-fact error message, a bug in Koha.
Cheers, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
"Joshua Ferraro" <jmf@liblime.com> wrote:
On Mon, Jun 23, 2008 at 5:18 AM, MJ Ray <mjr@phonecoop.coop> wrote:
1. put it in as a comment and POD string; [...] Which do people prefer? I'd lean towards doing (1 or 2) and 3. I prefer that all potential dependencies be clearly stated in the Makefile.PL, whether for optional features or not ... too many people installing Koha will perceive an after-the-fact error message, a bug in Koha.
So you're for option 1? Any optional features should probably guard themselves against use if their dependencies aren't available and/or have their system preference clearly labelled that they won't work without an optional dependency installed, else that is a bug in Koha. Requiring modules that we're not actually going to use is also a bug in Koha. Then too many people won't see an error because they'll be deterred by the long list of dependencies and never actually try Koha. I know for some tasks, I've tested perl software with a short dependency list first, and only tried a tool with a longer dependency list harder one if the easy one fails in some way - hasn't anyone else here done that? Regards, -- MJ Ray (slef) Webmaster for hire, statistician and online shop builder for a small worker cooperative http://www.ttllp.co.uk/ http://mjr.towers.org.uk/ (Notice http://mjr.towers.org.uk/email.html) tel:+44-844-4437-237 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
On Mon, Jun 23, 2008 at 1:10 PM, MJ Ray <mjr@phonecoop.coop> wrote:
Requiring modules that we're not actually going to use is also a bug in Koha.
I think that misconstrues the situation somewhat. We don't know what the end user is going to use. We have certain requirements to provide certain capabilities. It is not inherently wrong for the default installation to be "maximum capability", even if (for example) one given user never prints barcodes, and another never authenticates to LDAP. If the dependency is a reliable, widely compatible perl module, it should be treated as a Koha dependency, even if the feature it supports is logically severable. That is to say, we don't need to break Koha into 100 bits with frequently overlapping but "optional" dependencies. Each optional fragment should exist only because its dependencies are problematic or impossible for users to install correctly. Like Schedule::At not working on Win32 (no "at" command) makes it optional. Specifically, I don't think the "cost" in HDD space is significant given the profile of the project right now. I don't think it is worthwhile to add any complexity where the main payoff is allowing the user to *potentially* get a 400KB smaller installation. I can imagine that things would be different if we were working on an embedded application, or bundling larger deps like mysql and postgress. I still support developing a better way of accounting for the optional dependencies we do have, or migrating them to the kind of perl dependency that is unobjectionable. --Joe Atzberger _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
"Joe Atzberger" <ohiocore@gmail.com> wrote:
On Mon, Jun 23, 2008 at 1:10 PM, MJ Ray <mjr@phonecoop.coop> wrote:
Requiring modules that we're not actually going to use is also a bug in Koha.
I think that misconstrues the situation somewhat. We don't know what the end user is going to use. We have certain requirements to provide certain capabilities. It is not inherently wrong for the default installation to be "maximum capability", even if (for example) one given user never prints barcodes, and another never authenticates to LDAP.
Maybe not inherently wrong, but it is poor marketing, isn't it? If your certain requirements were documented, so others can decide if they share them - and ignore them if not - it wouldn't be so bad.
If the dependency is a reliable, widely compatible perl module, it should be treated as a Koha dependency, even if the feature it supports is logically severable. That is to say, we don't need to break Koha into 100 bits with frequently overlapping but "optional" dependencies. Each optional fragment should exist only because its dependencies are problematic or impossible for users to install correctly. Like Schedule::At not working on Win32 (no "at" command) makes it optional.
I think that's taking things to the wrong extreme. No need to break into a hundred parts, but expensive, awkward and/or niche things are probably worth being options - LDAP, image processing, cellphones...
Specifically, I don't think the "cost" in HDD space is significant given the profile of the project right now. I don't think it is worthwhile to add any complexity where the main payoff is allowing the user to *potentially* get a 400KB smaller installation. I can imagine that things would be different if we were working on an embedded application, or bundling larger deps like mysql and postgress.
I don't really understand this comment: the koha-en files take about 25Mb at present. By contrast, Image::Magick and its core libraries add 4.5Mb, without including the various bits of X which probably won't be installed on headless webservers otherwise. That's a significant 20% more. But disk space isn't my main concern: each extra dependency is a chance to cause problems for some users, to lose koha some testers.
I still support developing a better way of accounting for the optional dependencies we do have, or migrating them to the kind of perl dependency that is unobjectionable.
What way would you suggest? Thanks, -- MJ Ray (slef) Webmaster for hire, statistician and online shop builder for a small worker cooperative http://www.ttllp.co.uk/ http://mjr.towers.org.uk/ (Notice http://mjr.towers.org.uk/email.html) tel:+44-844-4437-237 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
On Mon, Jun 23, 2008 at 5:49 PM, MJ Ray <mjr@phonecoop.coop> wrote:
"Joe Atzberger" <ohiocore@gmail.com> wrote:
On Mon, Jun 23, 2008 at 1:10 PM, MJ Ray <mjr@phonecoop.coop> wrote:
Requiring modules that we're not actually going to use is also a bug in Koha.
I think that misconstrues the situation somewhat. We don't know what the end user is going to use. We have certain requirements to provide certain capabilities. It is not inherently wrong for the default installation to be "maximum capability", even if (for example) one given user never prints barcodes, and another never authenticates to LDAP.
Maybe not inherently wrong, but it is poor marketing, isn't it?
Not at all. I never drive 100MPH or accelerate 0 to 60 in the shortest possible time, but it is not "bad marketing" for Ford to have 100MPH on the speedometer, and to publish their performance times. Nobody will be scared off by dependencies that install themselves cleanly in the background without their intervention.
If the dependency is a reliable, widely compatible perl module, it should be treated as a Koha dependency, even if the feature it supports is logically severable. That is to say, we don't need to break Koha into 100 bits with frequently overlapping but "optional" dependencies. Each optional fragment should exist only because its dependencies are problematic or impossible for users to install correctly. Like Schedule::At not working on Win32 (no "at" command) makes it optional.
I think that's taking things to the wrong extreme. No need to break into a hundred parts, but expensive, awkward and/or niche things are probably worth being options - LDAP, image processing, cellphones...
This sounds like agreement. I rewrote the LDAP handling for Koha and it's dependencies are already optional. The feedback from earlier versions of the installer that indicated that was pretty poor though. Something like: You should run: perl -MCPAN -e 'install "If you want to authentify to LDAP, install Net::LDAP on your system.";' I.E., a message wrapped in the form of a broken command. Hopefully whatever method we use to account for optional components will be better than that. I'm fairly agnostic about our options because perl doesn't seem to have a "right" way of dealing with this.
Specifically, I don't think the "cost" in HDD space is significant given the profile of the project right now. I don't think it is worthwhile to add any complexity where the main payoff is allowing the user to *potentially* get a 400KB smaller installation. I can imagine that things would be different if we were working on an embedded application, or bundling larger deps like mysql and postgress.
I don't really understand this comment: the koha-en files take about 25Mb at present. By contrast, Image::Magick and its core libraries add 4.5Mb, without including the various bits of X which probably won't be installed on headless webservers otherwise. That's a significant 20% more.
I agree Image::Magick should be optional, but not because the 5MB is particularly significant. The main reason is that it cannot be reliably installed (the CPAN version not compiling on Debian, for example). Koha loses exactly zero real users over 5MB. You're comparison isn't apples-to-apples anyway. You'd need to compare the size of Koha's other system dependencies. But you say disk space isn't a main concern, so OK, we don't care about 5MB. Then besides our method of accounting for optional deps, the other question is how to categorize deps as friendly-enough-to-be-included or problematic-enough-to-be-optional. We should have one or more of the following: 1. Explicit criteria, so the developer knows which path to take. For example, that PurePerl modules are OK. This helps the developer know *before* the dep is added. 2. Specific systems (OS's) that we are targeting, such that compatibility on all of them would be sufficient. I want to acknowledge the tendency of this topic to drift off into OS wars and advise that we be strictly pragmatic. 3. A vetting process for proposed deps, ideally including buildbots or other automated checks. The automated steps help the developers catch problems *after* the dep is added (to test code, at least). --Joe Atzberger _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
"Joe Atzberger" <ohiocore@gmail.com> wrote:
On Mon, Jun 23, 2008 at 5:49 PM, MJ Ray <mjr@phonecoop.coop> wrote: [ Ever-increasing dependencies ]
Maybe not inherently wrong, but it is poor marketing, isn't it?
Not at all. I never drive 100MPH or accelerate 0 to 60 in the shortest possible time, but it is not "bad marketing" for Ford to have 100MPH on the speedometer, and to publish their performance times. Nobody will be scared off by dependencies that install themselves cleanly in the background without their intervention.
There we disagree a bit. Ford takes a kicking in the UK if they try to make a feature out of their top speed. It's also rather difficult to define "install themselves cleanly" well: are our use cases still the same as they used to be? [...]
This sounds like agreement. I rewrote the LDAP handling for Koha and it's dependencies are already optional. The feedback from earlier versions of the installer that indicated that was pretty poor though. Something like: You should run: perl -MCPAN -e 'install "If you want to authentify to LDAP, install Net::LDAP on your system.";'
Not to get into too much detail on an old, now-fixed bug: please everyone test releases on a naked system if possible! [...]
Then besides our method of accounting for optional deps, the other question is how to categorize deps as friendly-enough-to-be-included or problematic-enough-to-be-optional. We should have one or more of the following:
1. Explicit criteria, so the developer knows which path to take. For example, that PurePerl modules are OK. This helps the developer know *before* the dep is added. 2. Specific systems (OS's) that we are targeting, such that compatibility on all of them would be sufficient. I want to acknowledge the tendency of this topic to drift off into OS wars and advise that we be strictly pragmatic. 3. A vetting process for proposed deps, ideally including buildbots or other automated checks. The automated steps help the developers catch problems *after* the dep is added (to test code, at least).
4. No new required dependencies during the release engineering phase except to clear a blocker or critical bug. Regards, -- MJ Ray (slef) Webmaster for hire, statistician and online shop builder for a small worker cooperative http://www.ttllp.co.uk/ http://mjr.towers.org.uk/ (Notice http://mjr.towers.org.uk/email.html) tel:+44-844-4437-237 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
I'd like to see a warning page come up when updatedatabase runs that lists any new deps added. This would, of course, blur the meaning of kohaversion's db revision string if an added dep requires incrementing kohaversion to trigger updatedatabase, but it would be helpful for an admin who wants to run from git to get an appropriate warning. Ryan -- On Thu, Jun 26, 2008 at 9:30 AM, MJ Ray <mjr@phonecoop.coop> wrote:
On Mon, Jun 23, 2008 at 5:49 PM, MJ Ray <mjr@phonecoop.coop> wrote: [ Ever-increasing dependencies ]
Maybe not inherently wrong, but it is poor marketing, isn't it?
Not at all. I never drive 100MPH or accelerate 0 to 60 in the shortest possible time, but it is not "bad marketing" for Ford to have 100MPH on
"Joe Atzberger" <ohiocore@gmail.com> wrote: the
speedometer, and to publish their performance times. Nobody will be scared off by dependencies that install themselves cleanly in the background without their intervention.
There we disagree a bit. Ford takes a kicking in the UK if they try to make a feature out of their top speed. It's also rather difficult to define "install themselves cleanly" well: are our use cases still the same as they used to be?
This sounds like agreement. I rewrote the LDAP handling for Koha and it's dependencies are already optional. The feedback from earlier versions of the installer that indicated that was pretty poor though. Something
[...] like:
You should run: perl -MCPAN -e 'install "If you want to authentify to LDAP, install Net::LDAP on your system.";'
Not to get into too much detail on an old, now-fixed bug: please everyone test releases on a naked system if possible!
[...]
Then besides our method of accounting for optional deps, the other question is how to categorize deps as friendly-enough-to-be-included or problematic-enough-to-be-optional. We should have one or more of the following:
1. Explicit criteria, so the developer knows which path to take. For example, that PurePerl modules are OK. This helps the developer know *before* the dep is added. 2. Specific systems (OS's) that we are targeting, such that compatibility on all of them would be sufficient. I want to acknowledge the tendency of this topic to drift off into OS wars and advise that we be strictly pragmatic. 3. A vetting process for proposed deps, ideally including buildbots or other automated checks. The automated steps help the developers catch problems *after* the dep is added (to test code, at least).
4. No new required dependencies during the release engineering phase except to clear a blocker or critical bug.
Regards, -- MJ Ray (slef) Webmaster for hire, statistician and online shop builder for a small worker cooperative http://www.ttllp.co.uk/ http://mjr.towers.org.uk/ (Notice http://mjr.towers.org.uk/email.html) tel:+44-844-4437-237 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
-- Ryan Higgins LibLime * Open-Source Solutions for Libraries Featuring KohaZOOM ILS 888-564-2457 x704 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Joshua Ferraro a écrit :
On Mon, Jun 23, 2008 at 5:18 AM, MJ Ray <mjr@phonecoop.coop> wrote:
Warning: Reply-To set to koha-devel.
"Andrew Moore" <andrew.moore@liblime.com> wrote:
I guess it should be optional. Good point. If it's an optional dependency, how should I indicate that? Should I leave it out of Makefile.PL altogether?
I know no good way to indicate optional modules in Makefile.PL. Three choices that I think are better than total omission:-
1. put it in as a comment and POD string;
2. put it in as something like %CURRENT_PM like spamassassin does http://spamassassin.apache.org/full/3.0.x/dist/Makefile.PL
3. switch on META.yml generation and add a recommends line http://module-build.sourceforge.net/META-spec.html
Which do people prefer? I'd lean towards doing (1 or 2) and 3.
I prefer that all potential dependencies be clearly stated in the Makefile.PL, whether for optional features or not ... too many people installing Koha will perceive an after-the-fact error message, a bug in Koha.
Cheers,
I detinitely agree with your point of view. But what could also be a good behaviour would be to disable some links or some features if some perl module was not installed. But for image processing module, could be a pain for the developer that is willing to provide a new feature. Would allow more reliable installing and setting though. For instance, I have been said that SMS::Send even if not used or not desired would be required just becaus it was loaded in some core modules. If not, then error 500 would come out. I havenot investigated. But maybe we should be aware of the fact that adding a new dependency, should be done quite conciously and cautiously. And if dependency is not require, try and test on a fresh build bot so that it is proven that it is not generating errors not to install the perl module added. Hoping to be clear, midnight here. -- Henri-Damien LAURENT _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Hi Henri - thanks for your input on this. On Mon, Jun 23, 2008 at 5:08 PM, Henri-Damien LAURENT <laurenthdl@alinto.com> wrote:
For instance, I have been said that SMS::Send even if not used or not desired would be required just becaus it was loaded in some core modules. If not, then error 500 would come out.
I have really tried to avoid that, but if you find that is the case, please let me know. I'm happy to try to fix it.
I havenot investigated. But maybe we should be aware of the fact that adding a new dependency, should be done quite conciously and cautiously.
I thought I did that. Please let me know if there are more steps I should take next time.
And if dependency is not require, try and test on a fresh build bot so that it is proven that it is not generating errors not to install the perl module added.
I would like to do that very much. I've been struggling to get toward to state of having a smoke tester or a build server or a buildbot or something like that. If you have one set up, I encourage you to show us how we can get test results from it. Thanks! -Andy
Henri-Damien LAURENT <laurenthdl@alinto.com> wrote:
For instance, I have been said that SMS::Send even if not used or not desired would be required just becaus it was loaded in some core modules. If not, then error 500 would come out. I havenot investigated. But maybe we should be aware of the fact that adding a new dependency, should be done quite conciously and cautiously.
I can confirm the above example because I experienced it yesterday. SMS::Send also required three other perl modules which aren't packaged for that target platform AFAIK (MacOS X 10.4 Intel). Fortunately, all of them built fairly simply, which wasn't the case for Image::Magick on that platform. It would be great if 3.0.0-final has no new dependencies over 3.0.0-beta. Regards, -- MJ Ray (slef) Webmaster for hire, statistician and online shop builder for a small worker cooperative http://www.ttllp.co.uk/ http://mjr.towers.org.uk/ (Notice http://mjr.towers.org.uk/email.html) tel:+44-844-4437-237
On Wed, Jun 25, 2008 at 7:10 AM, MJ Ray <mjr@phonecoop.coop> wrote:
I can confirm the above example because I experienced it yesterday. SMS::Send also required three other perl modules which aren't packaged for that target platform AFAIK (MacOS X 10.4 Intel). Fortunately, all of them built fairly simply, which wasn't the case for Image::Magick on that platform.
Thanks for the help, MJ. I've opened bug http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2275 for this. -Andy _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
participants (6)
-
Andrew Moore -
Henri-Damien LAURENT -
Joe Atzberger -
Joshua Ferraro -
MJ Ray -
Ryan Higgins