Re: publicweb role

On Sunday, September 7, 2003 6:29, Greg Beaver wrote: > Tomas V.V.Cox wrote: >> My point with "app" is "any file which isn't a lib, doc, test or >> extension, that needs to be located at a custom place by the person >> who installs the package". Either if it is a standalone application or >> (as you said) it's used by an application. > After some thought, I begin to see a way to tweak this idea to solve all > the problems. > The main problem I see that needs solving (which app role might be part > of a solution) is that the URI to things like a javascript file must be > hard-coded in a .js file that includes other .js files, and the same > goes for .css files, or other static web-related things. replacements > will only work once: if a config variable changes, they must be redone. Yes, by reinstalling the application. I don't see other way. > With -c, they can be. This would require modifying the installer and > registry, however. The registry is designed to keep track of a single > installation location for a file. We would need to add a new registry > file devoted to tracking each app-specific install, so that all of them > will be uninstalled properly. Well, multiple installations of the same package looks like a difficult thing to manage. AFAIK no other package manager supports it. The problem comes when a package contains for example lib files (role="php") and app files (role="app"). You'd end with file conflicts when try to install a package multiple times. Well, we could train the users to release two packages instead, one with lib files (for ex: foo-base) and another with app specific data (foo-webfiles). $ pear -c app_dir=xxx install foo-webfiles $ pear -c app_dir=yyy install foo-webfiles $ pear list foo-webfiles[1] foo-webfiles[2] No very clear. > for an environment like a multi-user installation (or a lazy single user > one :), it would be good to have the -c option as a config variable, so > that pear install -C Packagename would use this config variable (avoids > typos which would be disastrous), or fail if it hasn't been set, and > pear -c /special/path Packagename would use the command-line version you > proposed. > Note that every package which contains this app role should show a > warning if neither -c nor -C is used, so users know about it. Maybe -C > could be turned on by default? > How does this sound: > 1) scrap publicweb > 2) add sub-roles for different kinds of application-specific data > role="app" subrole="web" (what used to be publicweb) > role="app" subrole="config" (configuration data like Pierre's > ~/.pear/blah) > 3) add configuration variables for the subroles which are blank by > default, and can be set to automate application variable-specific > installation. Also have a default subrole directory, which can be used > for all. I think this separation will be necessary, as not all packages > will want configuration files to be in a publicly accessible directory, > for example, but will want web files to be accessible. Why not instead of "subrole" we create a new replacement type? For example: <file role="app" name="index.html"> <file role="app" name="config.php"> <replace from="@web_uri@" to="web_uri" type="ask"> Web uri is the absolut location of the root dir in your site </replace> </file> @web_uri@: The string to replace in the code web_uri: The config var name ask: A new replacement type that will raise a message to the user in case the web_uri param is not passed "Web uri is..": The help message for this var So we'd end in: $ pear install foo This package contains ...., you need to pass the following options to the installer: - app_dir: The application root dir - web_uri: Web uri is the absolut location of the root dir in your site For example: pear -c app_dir=xxxx -c web_uri=xxx install foo -- Tomas V.V.Cox mailto:cox@idecnet.com