XDG_CONFIG_HOME
" in /etc/apache2/envvars to a writeable directory (in this case is /var/www). If I execute the script by itself from the www-data user works fine, it does not show that error message at all. Even if I check the /var/www directory after any execution I get the file created:XDG_CONFIG_HOME as a concept comes from the XDG base directory standard from the Linux Standards Base:I agree that it is somewhat confusing that the default is to use ~/.astropy, or $XDG_CONFIG_HOME/astropy if XDG_CONFIG_HOME is defined. This comes from the fact that we don't fully support the XDG standard, which states that the default should be ~/.config/astropy in the absence of XDG_CONFIG_HOME. But we went a different way because we didn't want to tell Linux and Mac users something different about where to find their config files.In any event, the issue you're running into is related to the log file, not a config file, which is stored in ~/.astropy/cache (by default) or $XDG_CACHE_HOME/astropy if XDG_CACHE_HOME is defined. So if you need to move it from the default location, you need to set XDG_CACHE_HOME in addition to XDG_CONFIG_HOME.While hopefully that workaround will work for you, it's possible that we could consider all of this required configuration as a bug. If we can't write to the config directory, we should proceed with defaults, and if we can't write to the cache directory, it might be possible to use a /tmp directory. I vaguely recall some discussion about this in the past, but looking at the code it doesn't appear that we do anything like this at the moment.
Both of these approaches needs the sysadmin to "touch" system configuration files which could bring future problems for other users and services. All this it's because I need a config file which I don't think I really need for these automated services. So, would it be possible to remove that dependency/feature? could we set some flags to remove the need of the config file?
Thanks,
David
Indeed, I thought we had an open issue for Astropy to just chill out
and (at most) emit a warning message if it has nowhere sensible to
write its config file and/or log. There is an issue. But I can't
find anything of the sort now, so maybe we should rethink this a bit
and open an issue for it.
> This does not solved my problem till I read properly the documentation and I
> created the $XDG_CONFIG_HOME/astropy directory.
> But this, in my case, is not a very good option.
I don't see why it's so bad--it's more or less the "right" way. The
objection that in the case of the webserver it requires a sysadmin to
create a directory under /var/www doesn't make sense to me since
presumably you already have that privilege if you're administering a
webserver. The reason that in your first use case it created
/var/www/.astropy is that /var/www is what the $HOME environment
variable was set to for your webserver.
That said, I agree there should be an option to just not touch the
filesystem at all if it isn't necessary to. I kind of hate it when
Python packages try to do anything on the filesystem at import time
beyond looking for other Python modules to import. But I think we
need to strike a balance here. The log and config files are useful
for ordinary users, and it has to be simple and more or less automatic
for those to be created in the normal use case. If $HOME/.astropy
can't be written, or if $XDG_CONFIG_HOME/astropy doesn't exist or
can't be created/written to then a config file shouldn't be used.
--
You received this message because you are subscribed to the Google Groups "astropy-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to astropy-dev...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.