I reply in the message. On Sunday, 19 June 2016 20:06:30 UTC-4, Anthony wrote: > > On Sunday, 19 June 2016 14:35:37 UTC-4, Anthony wrote: >>> >>> I suppose you could put web2py in one directory, and then symlink to an >>> application folder in some other directory. But it seems odd that you >>> somehow don't have control over how the application code gets updated. >>> There are lots of mechanisms by which you could update application code. >>> For example, if you need to ensure that after the files in an application >>> folder are updated some additional special file gets injected into the >>> folder, you could presumably use a script or an automation tool such as >>> Ansible to manage the whole process. >>> >>> >> It is not odd. You force me to be on the defensive. Please follow me with >> an analogy. In this analogy, the execution of an application is like going >> to a restaurant. A person entering the restaurant is like a request. The >> code is the menu. The bathroom is the configuration file where you need to >> go before you eat. The issue, in this analogy, is that the person needs to >> know where is the bathroom. Your solution is simply put the location of >> the bathroom in the menu. It's not stupid. It's true that, if we have a >> chain of restaurants, we could have a script that make sure that each menu >> has the correct location. My solution is simply to have the person ask >> when it enters the restaurant. >> > > I'm not sure I follow. You say you want your application to be able to > "ask" where the configuration file is. But you have simply pushed the > problem into the next layer -- now you have to determine how to ask, and > your application must know the protocol for asking. >
Yes, I am looking for a solution where the way to ask is fixed in the code by the author of the code and does not need to be modified by any installer. The trick of a wrapper application makes it easy. The wrapper application takes the burden of knowing the configuration location and it makes this information available to the wrapped application in some variable. The way to ask is simply to use that variable. This way to ask is fixed. The location can be different, because the installer creates or edit the wrapper application. Why is it any easier to know the protocol for asking than to simply know > what is being asked to begin with? Either way, you have to embed some data > in the application that enables it to know where/how to retrieve the > relevant information. > > For example, we could set things up so your application could retrieve the > location of a given configuration file by looking in > request.global_settings.config_filepath. But now we must encode the > identifier "request.global_settings.config_filepath" into the application > code. Why bother when it would be just as easy to include the file path > directly? > > Now I take it you might not want to include the file path directly because > perhaps the same application will be deployed on different systems, which > may keep the configuration file in different locations. But that's the > problem with your original request -- you did not make this clear. > Indeed the requirement is that the location must be determined by the installer and its content should never be modified in any update of the OS, language, framework or application. However, if we have a solution where the location (not only the way to ask for it) is fixed by the author of the code, I am interested. I believe that this is only possible if there is a general convention, used in all platforms, Windows, Linux, etc. all hosting services, shared servers, etc. available to the installers for such location. I don't believe that such convention exists, but even if it existed, I would still consider this as a second option, because I do not like the idea that we force the installer to use some location for configuration values. In particular, an installer might want to use the same folder for all languages and frameworks, putting all the configuration files together is not a bad idea. So, I offered you quite a number of different options, at least two of > which are quite simple and should satisfy your concerns: > > 1. Put the configuration data in a Python module, and have the application > import it. As long as the module is anywhere in the Python path on the > system (e.g., in site-packages), it will be available. > > 2. Use request.global_settings, which can be set in routes.py. > > I also tried to explain that the most important criteria for the location is that its content cannot be modified by an update of the operating system, the language, the framework or the application itself. For example, embedding the location in wsgihandler.py could be OK in that respect, because one can install web2py in the home folder (to protect it against OS update) and wsgihandler.phy is moved by the installer in the root before it is edited as needed, so (I believe) that it will not be modified if we update or reinstall web2py. However, as I said, I would also prefer that the location is chosen by the installer. > The bottom line is that you ultimately need some identifier or set of > identifiers encoded in the application itself in order to access the > configuration data. > > This is not true, not with the trick of a wrapper application. The wrapper application, not the application itself, has the identifier needed to access the configuration data and there is no constraint at all. Also, because the wrapper application is written by the installer, just as in the case of wsgihandler.py, it will not be modified by any re-installation or update of the OS, language, framework or wrapped application. It fulfills all the nice and natural requirements that I mentioned above. In PHP, you simply use the directory of the wrapped script as the new current directory and then include the wrapped script. I don't know what else needs to be explained. It's so simple. > It's not odd at all. I actually think that it is better, more natural, >> than your solution, which, I agree, is the common approach. >> > > Just to be clear, I wasn't saying your requirement was odd. I was saying > you made it sound as if you have no control over the environment in which > this application is being installed. Assuming you do have control, there > are lots of ways to tackle this problem, and the proper approach will > depend on the details of what needs to be static, what needs to be > modifiable, the nature of the environment(s), and the nature of the > deploy/update process. > > Actually, if all you need is to set some configuration options, you could >> do that by putting them in (a) a Python module that gets imported by the >> app, (b) a configuration file that gets loaded via AppConfig, (c) OS >> environment variables, etc. >> >> In my research, I already considered all these aspects. I am learning >> web2py and even python, but I am not new at these things. I will use (b), >> but this does not say where is the location of the config file. Yes (c) >> could be used to set the location of the configuration file or directly >> store the configuration, but it has its drawbacks. The location of the >> env. var. can depend on the systems. >> > > In Python, you would use os.getenv to retrieve an environment variable. > Why would the location depend on the system? Just use the same environment > variable name on each system. > > As mentioned above, if this works in the case of web2py, it would mean that some convention exists in all platforms, Windows, Linux, etc. all hosting services, shared servers, etc. Since Web2py is less available than PHP, it might be the case. I did not check that. However, remember the requirement: not erased in updates. Also, again, I would prefer that the location is fully under the control of the installer. -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
