Re: PHP application packaging policy/best practice?
Le Mer 12 Janvier 2005 01:31, Matthew Palmer a écrit : [No Cc needed, as per list policy] On Tue, Jan 11, 2005 at 11:47:42PM +0100, Pierre Habouzit wrote: it's _quite_ true that you don't need to play with include_path. your library has to know it's installed into /usr/share/php/app-or-library-name and either : * use some __FILE__ magic in its requires/includes * already use requires on app-or-library-name/*php files And I assume a lots of intern libraries are do not know how to do that. even some that ARE packaged into /usr/share/php/app-or-library-name what a mess. new try : It's only half-true that putting a lib into /usr/share/php/libname is fine. the lib has to be able to manage such a thing, and it's a requirement for a lib put into /usr/share/php/libname to be able to live there, without having to change anything in the include_path what I meant is that : libfile1.php live in /usr/share/php/mylib if libfile2.php has a : require 'libfile1.php'; anywhere, then it's not valid to package that lib in /usr/share/php/mylib, because libfile2.php NEEDS /usr/share/php/mylib to be in the include_path. So you patch libfile2.php to require_once 'mylib/libfile1.php' instead of just 'libfile1.php'. We've learnt to do this with C include files, why can't people work out the same thing for PHP? It's probably because of PHP's history as an easy, quick-hack language, that a lot of people with very little idea of even the basics of writing software have made an awful lot of really bad decisions... sure, but in C, you find the problem really quick : one compilation and you know if pathes are OK. in php, you cannot know ... you have to be really more careful. I hope this was more understandable that the previous post It is a bit easier, so I've replied to this one instead of your first. yeah, sorry, english is not my mother tongue, and after midnight, it's too difficult for me ;D -- ·O· Pierre Habouzit ··O OOOhttp://www.madism.org pgpajwMMykEfD.pgp Description: PGP signature
Re: PHP application packaging policy/best practice?
Le Mer 12 Janvier 2005 01:31, Matthew Palmer a écrit : So you patch libfile2.php to require_once 'mylib/libfile1.php' instead of just 'libfile1.php'. oh and btw, the suggestion I did is better (IMHO) : replace require_once 'libfile.php'; with require dirname(__FILE__).'/'.'libfile1.php'; because you are robust to _any_ mess done by the user with the include_path (for a zero cost). You even not assume that /usr/share/php is in the include_path. -- ·O· Pierre Habouzit ··O OOOhttp://www.madism.org pgpHcHPqykJsy.pgp Description: PGP signature
Re: PHP application packaging policy/best practice?
On Wed, Jan 12, 2005 at 10:13:05AM +0100, Pierre Habouzit wrote: Le Mer 12 Janvier 2005 01:31, Matthew Palmer a ?crit : [No Cc needed, as per list policy] On Tue, Jan 11, 2005 at 11:47:42PM +0100, Pierre Habouzit wrote: it's _quite_ true that you don't need to play with include_path. your library has to know it's installed into /usr/share/php/app-or-library-name and either : * use some __FILE__ magic in its requires/includes * already use requires on app-or-library-name/*php files And I assume a lots of intern libraries are do not know how to do that. even some that ARE packaged into /usr/share/php/app-or-library-name what a mess. new try : It's only half-true that putting a lib into /usr/share/php/libname is fine. the lib has to be able to manage such a thing, and it's a requirement for a lib put into /usr/share/php/libname to be able to live there, without having to change anything in the include_path what I meant is that : libfile1.php live in /usr/share/php/mylib if libfile2.php has a : require 'libfile1.php'; anywhere, then it's not valid to package that lib in /usr/share/php/mylib, because libfile2.php NEEDS /usr/share/php/mylib to be in the include_path. So you patch libfile2.php to require_once 'mylib/libfile1.php' instead of just 'libfile1.php'. We've learnt to do this with C include files, why can't people work out the same thing for PHP? It's probably because of PHP's history as an easy, quick-hack language, that a lot of people with very little idea of even the basics of writing software have made an awful lot of really bad decisions... sure, but in C, you find the problem really quick : one compilation and you know if pathes are OK. in php, you cannot know ... you have to be really more careful. I'm sure you'll get user feedback quickly enough... and a quick grep and scan usually picks up most of the problems. - Matt signature.asc Description: Digital signature
Re: PHP application packaging policy/best practice?
[No Cc please, as per list policy] On Wed, Jan 12, 2005 at 10:16:43AM +0100, Pierre Habouzit wrote: Le Mer 12 Janvier 2005 01:31, Matthew Palmer a ?crit : So you patch libfile2.php to require_once 'mylib/libfile1.php' instead of just 'libfile1.php'. oh and btw, the suggestion I did is better (IMHO) : replace require_once 'libfile.php'; with require dirname(__FILE__).'/'.'libfile1.php'; because you are robust to _any_ mess done by the user with the include_path (for a zero cost). You even not assume that /usr/share/php is in the include_path. But it has two giant downsides: 1) It's ugly as all hell; and 2) Once people start getting into that habit, they forget all about other libraries, and where they might be, and start complaining bitterly and/or bundling other peoples' libraries into their libraries, which creates a mess. There's also the issue of how to get to the library in the first place from your application -- you then either need to hard-code the path somewhere in your app (which, if you do, I *will* beat you with a stick) or you're back to needing the include_path, which means that all of your dirname() magic isn't needed anyway. Oh, another useful tidbit -- file namespaces are useful. library/libfile1.php isn't very likely to conflict with another library/libfile1.php that someone wants to install, whereas libfile1.php could very well conflict. - Matt signature.asc Description: Digital signature
Re: PHP application packaging policy/best practice?
On Wed, Jan 12, 2005 at 10:16:43AM +0100, Pierre Habouzit wrote: Le Mer 12 Janvier 2005 01:31, Matthew Palmer a ?crit : So you patch libfile2.php to require_once 'mylib/libfile1.php' instead of just 'libfile1.php'. oh and btw, the suggestion I did is better (IMHO) : replace require_once 'libfile.php'; with require dirname(__FILE__).'/'.'libfile1.php'; because you are robust to _any_ mess done by the user with the include_path (for a zero cost). You even not assume that /usr/share/php is in the include_path. But it has two giant downsides: 1) It's ugly as all hell; and 2) Once people start getting into that habit, they forget all about other libraries, and where they might be, and start complaining bitterly and/or bundling other peoples' libraries into their libraries, which creates a mess. There's also the issue of how to get to the library in the first place from your application -- you then either need to hard-code the path somewhere in your app (which, if you do, I *will* beat you with a stick) or you're back to needing the include_path, which means that all of your dirname() magic isn't needed anyway. Oh, another useful tidbit -- file namespaces are useful. library/libfile1.php isn't very likely to conflict with another library/libfile1.php that someone wants to install, whereas libfile1.php could very well conflict. well I agree it's not _that_ perfect. It's only that from a packager POV I find it more safe. I've looked at PEAR's ways. and it does not use such mechanism. only the namespace trick. Well, I think it's the coder choice then ... -- ·O· Pierre Habouzit ··O OOOhttp://www.madism.org pgpRMMMUug9tJ.pgp Description: PGP signature
Re: PHP application packaging policy/best practice?
Le vendredi 07 janvier 2005 à 14:19 +0100, Kees Leune a écrit : Hi, I am preparing an ITP for a PHP application that is currently under development at my place of employment. While thinking about packaging it, I was wondering if there is any PHP application policy or best practice. I am now leaning to a setup as follows: /usr/lib/appname/php Publicly loadable PHP pages /usr/lib/appname/libIncluded PHP libraries (not reachable via httpd) /var/lib/appname Persistant data /etc/appname/appname.cfg Configuration /etc/appname/apache.conf Apache configuration (symlink from /etc/apache/conf.d) Note that I chose /usr/lib over /usr/share because according to the FHS, /usr/share is meant for all read-only architecture independent data files. Although PHP files are read-only and architecture indepedent, I consider them as programs. Any thoughts? I collected some interesting Debian packaging Web Applications policy drafts some time ago: http://glasnost.beeznest.org/articles/184 I accept any comments, especially improvements of course. -Kees
Re: PHP application packaging policy/best practice?
hi there, On Sat, Jan 08, 2005 at 03:05:15PM +0100, Jérôme Warnier wrote: Any thoughts? I collected some interesting Debian packaging Web Applications policy drafts some time ago: http://glasnost.beeznest.org/articles/184 to throw another link out: http://people.debian.org/~seanius/policy/ right now, there's a heck of a lot more work done on the database-specific aspect of web-applications, though it's my intention to eventually cover the whole gamut. my two recommendations are to use /usr/share/$pkg (or a subdir) for the application pages, and don't modify configuration files of other packages. sean -- signature.asc Description: Digital signature
Re: PHP application packaging policy/best practice?
Le samedi 08 janvier 2005 à 18:32 -0500, sean finney a écrit : hi there, On Sat, Jan 08, 2005 at 03:05:15PM +0100, Jérôme Warnier wrote: Any thoughts? I collected some interesting Debian packaging Web Applications policy drafts some time ago: http://glasnost.beeznest.org/articles/184 to throw another link out: http://people.debian.org/~seanius/policy/ You obviously didn't take a look at my page. :-P This link is the first one on my list. right now, there's a heck of a lot more work done on the database-specific aspect of web-applications, though it's my intention to eventually cover the whole gamut. my two recommendations are to use /usr/share/$pkg (or a subdir) for the application pages, and don't modify configuration files of other packages. sean
Re: PHP application packaging policy/best practice?
Quoting Kees Leune [EMAIL PROTECTED]: Hi, I am preparing an ITP for a PHP application that is currently under development at my place of employment. While thinking about packaging it, I was wondering if there is any PHP application policy or best practice. I am now leaning to a setup as follows: /usr/lib/appname/php Publicly loadable PHP pages /usr/lib/appname/libIncluded PHP libraries (not reachable via httpd) /var/lib/appname Persistant data /etc/appname/appname.cfg Configuration /etc/appname/apache.conf Apache configuration (symlink from /etc/apache/conf.d) Note that I chose /usr/lib over /usr/share because according to the FHS, /usr/share is meant for all read-only architecture independent data files. Although PHP files are read-only and architecture indepedent, I consider them as programs. Any thoughts? Horde and its associated applications install to /usr/share, if that makes any difference to you. -Roberto Sanchez This message was sent using IMP, the Internet Messaging Program.
Re: PHP application packaging policy/best practice?
On Fri, 07 Jan 2005, Kees Leune wrote: /usr/lib/appname/php Publicly loadable PHP pages /usr/lib/appname/libIncluded PHP libraries (not reachable via httpd) /var/lib/appname Persistant data /etc/appname/appname.cfg Configuration /etc/appname/apache.conf Apache configuration (symlink from /etc/apache/conf.d) Note that I chose /usr/lib over /usr/share because according to the FHS, /usr/share is meant for all read-only architecture independent data files. Although PHP files are read-only and architecture indepedent, I consider them as programs. That's not enough a reason to go with lib/ in Debian IMHO. Have a look on share/, and you will find that pratically everything arch-independent goes in there. php itself does this. Another hint that Debian doesn't make much of a distinction between executables and data is the lack of libexec/ -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
