> > 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. >
I don't think the concept of "wrapper application" is well defined. In any case, we should probably drop that idea, as your ultimate goal is not to have a "wrapper application" but instead to have some configuration data made available to your application -- so let's focus on that. > 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. > This is still somewhat vague. What is the nature of the "installer" (is that a person or a program)? Are you referring to the installation of the web2py framework and the setting up of the configuration data, the installation of the application, both? Exactly how will the application itself be installed/updated? > 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. > You have now been given five options that would not be affected by any updates: 1. Use a Python module, installed anywhere in the Python path, the most obvious place being /web2py/site-packages. 2. Add keys to gluon.settings.global_settings in /web2py/routes.py, and access the data via request.global_settings in the application. 3. Set an OS environment variable. 4. Put a configuration file in a standard location, such as /web2py/config.ini. The app could find the file via os.path.join(request.env.web2py_path, 'config.ini'). In this case, the app only needs to know the filename but not its path. Another option would be to put the file in the application folder itself, assuming the folder is not simply overwritten upon update. 5. Use WSGI middleware, which would involve some custom code in /web2py/wsgihandler.py. However, as I said, I would also prefer that the location is chosen by the > installer. > Even if the location of a configuration file is chosen by the installer, the installer must still put *some* data in a standard location so the application knows how to access it (i.e., the application needs a standard API to tell it how to retrieve the path of the configuration file). As long as we're constraining the installer to provide this data in a standard location, why not constrain the location of the configuration file itself (in particular, make sure it goes somewhere inside the /web2py directory tree)? Is that configuration file going to be used by some other software besides web2py? 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. > I think you misunderstood my point. By "identifier," I just mean anything the application uses to access some piece of data, whether a Python object name or a plain string. For example, as already noted, we could inject the needed data via request.global_settings.config_filepath, but then the name "request.global_settings.config_filepath" itself is an identifier that the application must know about. > 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. > That sounds different from a full web framework and web application, with models, views, controllers, routing, etc. How does it look in something like Laravel, Codeigniter, etc.? 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. >> > > Yes, the variable can be the same. As mentioned above, if this works in > the case of web2py, it would mean that some convention exists for the > availability of such environment storage in all platforms, Windows, Linux, > etc. all hosting services, shared servers, etc. > Yes, a convention does exist (most platforms where web2py runs should have the ability to set environment variables), and environment variables can be set and retrieved from Python via a standard interface. > Also, again, I would prefer that the location is fully under the control > of the installer. Even the location of a variable that contains the > location of the config file should preferably not be a fixed os environment > variable. > Not sure what you mean by "location of a variable" here. Environment variables are just a key-value store -- you just have to know the key, and you can retrieve the value. In your application code, what's the difference between: config_filepath = some_global_settings_object.config_filepath and config_filepath = os.environ['WEB2PY_CONFIG_FILEPATH'] Both alternatives provide a consistent way for the app to access the filepath (that would work on every platform), and both require the application code to know some identifier to get that filepath (i.e., "some_global_settings_object.config_filepath" in one case vs. "WEB2PY_CONFIG_FILEPATH" in the other). > > Do you have more information about global_settings. Here is what I got > from the Web2Py book: > > > *request.global_settings contains web2py system wide settings. They are > set automatically and you should not change them. For example > request.global_settings.gluon_parent contains the full path to the web2py > folder, request.global_settings.is_pypy determines if web2py is running on > PyPy.* > > I want to know if it can be used as storage and if that storage will be > preserved on updates of web2py. It does not look promising. > You should not change the specific keys that web2py sets, but you can add your own keys. And the recommendation was to add your settings in routes.py, which will not change when you update web2py. Anyway, this is not my top recommendation, just one possibility. > I also looked at os.environ.get. It seems that the installer would need > some privileged access to the environment, which he might not have in some > hosted services. In contrast, you need no extra privilege at all with the > wrapper application trick. If you can install the application, then you can > install the wrapper application. > Probably any host where you can run web2py would allow you to set environment variables (note, web2py will not run on all shared hosts). Anyway, I don't necessarily recommend using environment variables or request.global_settings, as I think simply importing a Python module from /web2py/site-packages or specifying a standard config file name to be found in the /web2py folder or the app folder would be the simplest approaches and would meet your requirements. Finally, your suggestion to modify wsgihandler.py to create a wrapper over > the application seems to be the most promising. It is what I asked for. > I think you're over-complicating things because you think you need a "wrapper application," which perhaps you have used in some other more simplified context (such as with a basic PHP script). Anthony -- 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 web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
