Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#9170 closed defect (duplicate)

php/aspell conflict

Reported by: jwm4 Owned by: lschiere
Milestone: Component: unclassified
Version: 2.5.5 Keywords:
Cc:

Description

Why does Pidgin (or more specifically, datallah) bullheadedly insist that the problem here is that PHP instructs its Windows users (of which there are many, not a "few" as suggested by datallah - see # WAMP downloads) to include their php directory as a PATH Environment variable. Why insist there is only the "Pidgin" way to resolve this issue (remove PHP directory from PATH)?

Let's face facts. PHP is a development and application platform that runs thousands of applications and millions of websites. Pidgin is a single application. So, faced with the choice of which either configuring PHP in a nonstandard manner in order to allow Pidgin to work correctly with aspell, doing without Pidgin or installing Pidgin without Aspell (my choice), most will go with one of the latter two choices. Perhaps as an open source software organization, the Pidgin leadership does not care that this attitude results in either fewer Pidgin users (# who make the no Pidgin choice or fewer fully satisfied Pidgin users (# who make the no Aspell choice).

Frankly, I find the "our way or the highway" attitude that underlies this approach troublesome and unnecessary. It's one of the less attractive tendencies of open source software (and surprisingly reminiscent of the 1990's behavior of Microsoft, often cast as the villain by the open source community), and one that will not be found (for long) in a proprietary, profit-seeking software development firm.

Just my two cents.

Change History (8)

comment:1 Changed 7 years ago by rekkanoryo

  • Resolution set to duplicate
  • Status changed from new to closed

Closed as duplicate of #7750.

Putting random crap in PATH is a bad idea, and instructing users to add directories to PATH is just plain stupid. If you're unwilling to accept that the PHP people are, in fact, capable of doing stupid things, that's not our problem.

comment:2 Changed 7 years ago by deryni

I'd like to point out, for the record, that inherent in the supposition that we should be doing something about this is the fact that we must accept either the "PHP way or the highway" exactly as much as you insinuate it works in the other direction.

comment:3 Changed 7 years ago by rekkanoryo

Note also that it's impossible for us to work around the incompatible aspell, thus enforcing deryni's point.

comment:4 Changed 7 years ago by datallah

As a side note, future versions of PHP will not pollute the path with an incompatible aspell dll.

comment:5 follow-up: Changed 7 years ago by jwm4

Glad to see you enjoying yourselves while proving my point about the unattractive, customer-be-damned attitude of some open source software organizations. Pidgin clearly falls in that category.

Out of curiosity, I did look into your proposed app path solution for PHP. I am not a programmer, by the way, just a plain, old business guy, with lots of experience evaluating, investing in and managing info tech businesses. From what I could discern, it would take considerable laborious effort for one to determine all the specific PHP modules/extensions, their dll's and dll locations as required to implement your "app path" solution, especially if one has installed PEAR with PHP. To undertake such an effort without very detailed instructions from the PHP/PEAR communities (which i could not find) would most likely result in a failed PHP installation. All so that spell check would work in an instant messenger? Give me a break.

It appears that Pidgin's customer support/quality assurance/bug fixing team, apparently supported by Pidgin's leaders, offers a perfect case study in how to: 1) blame and criticize customers for following the install instructions of one of the largest, most successful and most respected open source software organizations; 2) offer a "solution" that is impractical to implement without detailed support and guidance from PHP/PEAR, which Pidgin apparently has done nothing to obtain; 3) NOT work harmoniously and productively with other open source organizations to solve shared customer problems.

Suit yourselves. If your leadership continues to support such behavior, it will not be long before another open source organization that takes a much more proactive, customer (that is the correct word, not user) centric perspective and passes Pidgin by. I've already identified several likely candidates, will be installing their IM and uninstalling Pidgin. Have a nice day.

comment:6 Changed 7 years ago by deryni

Did you not read rekkanoryo's comment? We cannot work around the issue. Did you not read datallah's comment? PHP has stopped shipping (from what I can tell, datallah correct me if I'm wrong) the incompatible dll thus allowing things to work without issue.

Your claim is that somehow because PHP is more important we should somehow come up with a way to avoid incompatibilities with libraries we use caused by the PHP installer and that somehow by deciding not to work around them (because doing so is actually impossible) we are blaming people for something and that it should be our job to help users install someone else's software so it works with our software.

You seem to be laboring under the belief that we have done something to cause this problem, we haven't, PHP has. The PHP installer has placed a dll which other applications may want to use a different version of in the PATH thus forcing the applications to get that copy instead of the one they might otherwise have expected, we didn't do anything here other than install aspell in a way that allows other appliations to use it and not require each application to install their own copy of it.

At no point did we blame or criticize users for doing this, we did inform them that they shouldn't and instructed them to undo it (in ways you may consider unnecessarily harsh, but were not intended as such). I also do not share your characterization of the relative merits and statuses of pidgin versus PHP (but that is neither here nor there and only serves to color your outrage and not actually help the situation).

Your tone in all of this has been incredibly angry, accusative, and confrontational and has only gotten more so as we have attempted to explain (yet again) why this is not an issue of our making and that polluting the system PATH is not a good idea (for reasons of application compatability exactly like this), something that is decidedly unpleasant and unlikely to engender responses that are not in kind.

comment:7 Changed 7 years ago by datallah

I don't know if they have stopped shipping the broken aspell dll or it is just that they will stop in an upcoming version (because it will use enchant and hunspell(?)).

I'm not sure where this polemic attitude came from, but it certainly doesn't help your cause.

comment:8 in reply to: ↑ 5 Changed 7 years ago by rekkanoryo

Replying to jwm4:

It appears that Pidgin's customer support/quality assurance/bug fixing team, apparently supported by Pidgin's leaders, <snip>


The people who man this bug tracker are Pidgin's developers, and that includes deryni, datallah, and myself. We have no "quality assurance team" or any other team.


Suit yourselves. If your leadership continues to support such behavior, it will not be long before another open source organization that takes a much more proactive, customer (that is the correct word, not user) centric perspective and passes Pidgin by. I've already identified several likely candidates, will be installing their IM and uninstalling Pidgin. Have a nice day.


We do not have customers, nor do we have clients. We are not a business. We are a small group of people who volunteer to develop and support Pidgin and libpurple. The terms "customer" and "client" infer that there is a contract between Pidgin developers and users, and there is no such contract. We are not obligated to provide any form of support, nor are we even obligated to provide the precompiled Windows binaries. Our obligation begins and ends at making the source code available to our users.

All that said, if any of this is unacceptable, it is of course your prerogative to find another IM client. Open-source software is allegedly partially about choice, and freedom of choice, so if you find another client more suitable, feel free to use it. We certainly aren't going to try to stop anyone from using or not using Pidgin.

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!