{"issue":{"pull_request":{"diff_url":"https://github.com/astropy/astropy/pull/35.diff","html_url":"https://github.com/astropy/astropy/pull/35","patch_url":"https://github.com/astropy/astropy/pull/35.patch"},"state":"open","user":{"avatar_url":"https://secure.gravatar.com/avatar/b2a66b4a75397bcd42fdd7bb399ee553?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","gravatar_id":"b2a66b4a75397bcd42fdd7bb399ee553","url":"https://api.github.com/users/eteq","login":"eteq","id":346587},"milestone":null,"assignee":null,"labels":[],"updated_at":"2011-11-01T18:26:59Z","comments":19,"closed_at":null,"url":"https://api.github.com/repos/astropy/astropy/issues/35","body":"This pull request implements the layout of the `config` package, And also implements functionality for remote download/caching of data files and configuration file utility functions.  \r\n\r\nThe remote data aspect of this is ready to go (including tests).  One choice I ended up making that could be changed if desired: As it stands right now, data included in the source distribution should live in the astropy/data directory (or subdirectories), rather than in data directories scattered around in each package.  If that's strongly desired, it can probably be implemented, although it may require fiddling with setup.py.  I shy aware from that because it'll be confusing for future developers - specifically, how does the directory structure of package map onto the directory structure in the data directory?  It could be multiple ways, but the simplest thing is to just put them all in one place.\r\n\r\nAs for the configuration files, there are a few questions to be addressed:\r\n\r\n* Should this simple interface (``get_config('subpackagename')``) be it?  I could implement a scheme where package authors could just define constants at the top of the modules and have them automatically get passed out to the configuration files (or a new version adopted or whatever), but I wasn't sure what everyone else wanted, so I started with this basic interface (which will be useful in more complicated cases, anyway).\r\n* Right now, the configuration files and remote data cache are in $HOME/.astropy ... given that affiliated packages will want to use this stuff, should we use the ``.astropy`` name?  Right now, inside that directory there will be directories with the name e.g. ``astropy`` for the astropy core, ``afpkg1`` for the first afilliated package, and so on... You specify which one you want with the second argument to ``get_config``. This could change to have separate main directories for each affiliate package, but I think this is easier to deal with, as it doens't clutter up the user's home directory.\r\n* In the docstring for ``get_config`` I'm pointing to the configobj web site for definitions of the ConfigObj object and its interface.  Should I pull in a copy of the ConfigObj documentation and included it in the sphinx docs (just as a separate html file include in the source dist)?\r\n\r\nOnce this has been decided on and the pull request completed, I will write up documentation describing how to use these modules in the sphinx docs and issue a new pull request.","html_url":"https://github.com/astropy/astropy/issues/35","title":"Config package and data downloaders","number":35,"id":2066315,"created_at":"2011-10-27T10:18:08Z"},"action":"created","comment":{"user":{"avatar_url":"https://secure.gravatar.com/avatar/c7d341e2b002754f2b21fbab3a3fd072?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","gravatar_id":"c7d341e2b002754f2b21fbab3a3fd072","url":"https://api.github.com/users/iguananaut","login":"iguananaut","id":676149},"updated_at":"2011-11-01T18:26:59Z","url":"https://api.github.com/repos/astropy/astropy/issues/comments/2593916","body":"@eteq: And I see _your_ point about environment variables.  Maybe if a value is used from an environment variable there should be a notice in the log so that there's at least some record that can be checked as to where the value is coming from.  And like I said, this could be implemented separately from the rest of this pull request so I will write it up in a separate issue.\r\n\r\nA Configuration wrapper object would also make a multi-file scheme easier, since it could worry about merging the files and such.  Either way it's useful to have.\r\n\r\nAs for configspec, ConfigObj supports a configspec file that lists all the sections/options that are valid, and includes validation for each option.  However, I do like the idea of defining options at the module level as module-global variables.  The ConfigObj validation machinery can be used programmatically as well, so we can get the same functionality whether all options are defined in one file, or if they're defined programmatically in each module.\r\n\r\nThe advantage of the former is that it's easy to see all the options and their allowed values in one place.  But if they're defined programmatically there could still be a function to list them all.  The only problem I see with that is that to check if a module has options defined it would have to go through and import each module.  So maybe they should only be defined at the subpackage-level in \\__init__.pys.","id":2593916,"created_at":"2011-11-01T18:26:59Z"}}