You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So far so good. But how can i avoid attempting to read a config at all?
Purpose is avoiding side effects which may result from reading a config outside of the daemon's config system.
I think you might be able to set an environment variable to change the config directory, and you could point it to a temporary empty directory. Need to look into what the variables are called.
Looks like the solution is to make a temporary directory, and make a directory called astropy in it, then set XDG_CONFIG_HOME to point to the temporary directory:
Well, I, for one, am not terribly happy with either solution -- you see, the
problem is that these days, it's hard to tell which modules will end up
importing astropy, which then results in either a warning message if I'm
lucky (yes, I know I could shut it up) or the loading of user-specific
configuration if a user starts the server in debug mode if I'm unlucky.
Setting XDG_CONFIG_HOME early on is tricky because I'd actually like to
point it to a server-defined position, which I only have available when
my the server's configuration is loaded. Making sure that has happened
before an import of anything pulling in astropy is possible, but feels a
bit brittle.
The context manager could, of course, control the whole server process.
But it has the same issue: Much rather mkdtemp-ing something somewhere,
I'd much rather have a controlled location, which I'd only get after my
own configuration is available (e.g., in case I later want server
operators to use a well-defined, server-specific configuration), which
is again not easy to ensure.
So, what I've been doing so far is exploit an implementation detail: a
import__builtin____builtin__._ASTROPY_SETUP_=True
very early on. If something like that became sanctioned use, I'd be a
happy camper.
Abusing builtin is, of course, not ideal. But couldn't astropy use a
documented environment variable (ASTROPY_USE_BUILTIN_CONFIG?) here? I'd
suspect it might help your setup code, too.
[Disclosure: I'm working with @funbaker, so this isn't really an
independent opinion]
@funbaker@msdemlei - have you seen solutions in other packages that you think we should emulate? Other packages such as ipython have user-level configuration, and as far as I know one can't just import IPython ignoring the configuration directory. I would be hesitant to implement a special case solution in Astropy if other packages don't do it too, and on the other hand if there is a well defined mechanism for doing this, we are happy to try and implement it here.
Just so I understand, do you actually expect the configuration to have been modified from its default values? If so, by who?
Revisiting this, I think this is a valuable feature to have especially when dealing with computing cluster or "serverless" applications. Perhaps a resurrection of #5907 is in order (see #10090).
I think it would make sense to suppress downstream packages that uses astropy.config.configuration.get_config() too, as they also would experience the same problem. What do you think, @Cadair ?
Activity
pllim commentedon Mar 22, 2017
That would defeat the purpose of a configuration system... What exactly is your use case?
funbaker commentedon Mar 22, 2017
Using astropy in a daemon with it's own configuration system.
pllim commentedon Mar 22, 2017
You can overwrite default config values in your script if you don't want to use daemon defaults...
http://docs.astropy.org/en/stable/config/#changing-values-at-run-time
funbaker commentedon Mar 22, 2017
So far so good. But how can i avoid attempting to read a config at all?
Purpose is avoiding side effects which may result from reading a config outside of the daemon's config system.
astrofrog commentedon Mar 22, 2017
I think you might be able to set an environment variable to change the config directory, and you could point it to a temporary empty directory. Need to look into what the variables are called.
astrofrog commentedon Mar 22, 2017
Looks like the solution is to make a temporary directory, and make a directory called
astropyin it, then setXDG_CONFIG_HOMEto point to the temporary directory:https://github.com/astropy/astropy/blob/master/astropy/config/paths.py#L97
astrofrog commentedon Mar 22, 2017
Same goes for cache, with
XDG_CACHE_HOME: https://github.com/astropy/astropy/blob/master/astropy/config/paths.py#L138astrofrog commentedon Mar 22, 2017
The other solution is to use the following context manager: https://github.com/astropy/astropy/blob/master/astropy/config/paths.py#L208
pllim commentedon Mar 23, 2017
@funbaker , if what astrofrog suggested works for you, please close this issue.
msdemlei commentedon Mar 23, 2017
Well, I, for one, am not terribly happy with either solution -- you see, the
problem is that these days, it's hard to tell which modules will end up
importing astropy, which then results in either a warning message if I'm
lucky (yes, I know I could shut it up) or the loading of user-specific
configuration if a user starts the server in debug mode if I'm unlucky.
Setting XDG_CONFIG_HOME early on is tricky because I'd actually like to
point it to a server-defined position, which I only have available when
my the server's configuration is loaded. Making sure that has happened
before an import of anything pulling in astropy is possible, but feels a
bit brittle.
The context manager could, of course, control the whole server process.
But it has the same issue: Much rather mkdtemp-ing something somewhere,
I'd much rather have a controlled location, which I'd only get after my
own configuration is available (e.g., in case I later want server
operators to use a well-defined, server-specific configuration), which
is again not easy to ensure.
So, what I've been doing so far is exploit an implementation detail: a
very early on. If something like that became sanctioned use, I'd be a
happy camper.
Abusing builtin is, of course, not ideal. But couldn't astropy use a
documented environment variable (ASTROPY_USE_BUILTIN_CONFIG?) here? I'd
suspect it might help your setup code, too.
[Disclosure: I'm working with @funbaker, so this isn't really an
independent opinion]
astrofrog commentedon Mar 23, 2017
@funbaker @msdemlei - have you seen solutions in other packages that you think we should emulate? Other packages such as ipython have user-level configuration, and as far as I know one can't just import IPython ignoring the configuration directory. I would be hesitant to implement a special case solution in Astropy if other packages don't do it too, and on the other hand if there is a well defined mechanism for doing this, we are happy to try and implement it here.
Just so I understand, do you actually expect the configuration to have been modified from its default values? If so, by who?
funbaker commentedon Mar 24, 2017
I added a pull request with Code and Tests that implements this feature in an opt-out manner...
pllim commentedon Mar 30, 2020
Revisiting this, I think this is a valuable feature to have especially when dealing with computing cluster or "serverless" applications. Perhaps a resurrection of #5907 is in order (see #10090).
pllim commentedon Mar 30, 2020
I think it would make sense to suppress downstream packages that uses
astropy.config.configuration.get_config()too, as they also would experience the same problem. What do you think, @Cadair ?