This pull request seems fine to me. I like the layout. I definitely agree with adding dev (not alpha) at the end of the version numbers, and I agree that the equivalent revision number would be useful (note we could also just use the 6 first characters of the SHA, but I agree it's less intuitive). The only comment I have is regarding making version available, but to be honest this can be added later.

I agree that adding the __version__ variable makes sense, so I just updated it to do so. I also updated .gitignore to ignore some of the files we definitely want to ignore (after almost adding a .pyc file...)

I may want to have a couple in our branch look at this. Is it typical to have the C extensions that separated from the Python code? Usually they are tightly coupled with a particular module or package and I wonder if it makes sense to put things in two different places. What is the advantage of doing that?

The advantage of a separate /extern directory for c code is that you can put "un-altered" C libraries in there so that they don't need to be downloaded separately, but can be easily updated in their own directories when the upstream library is updated.

The /astropy/wrappers directory is for the wrappers for the /extern c libraries only - it's in /astropy because it's clearer to have the Cython/C code be where it actually ends up in terms of the python package layout, but remain separated out so that it's clear that that code is directly interfacing with the /extern C libraries.

The intent is that any Cython or C code that is not directly related to an external library gets placed in the particular module it is used in, exactly as you say. These two separated directories are only meant for pre-existing C-libraries that need to be wrapped.

This looks good to me as a starting template, other than my above comment about namespace packages. That's not really an actionable comment at this point though, as there has been no discussion about it. My point about namespace packages, however, is that if astropy is going to be a large platform, it may be desireable to break out at least parts of it into separate optional installables, in which case namespace packages are the way to go. I don't know if anyone else had this in mind though.

[And as an aside on namespace packages in general, I'm aware that there's been discussion in scikits about not using them anymore, but I think that's misguided, especially in anticipation of PEP 382/402, either of which will make them easier to deal with once accepted.]

Actually, the intent as specified in the vision and coding guidelines is specifically not to have astropy be a namespace package. The idea is that the astropy package contains all the core functionality, and everything else uses the "awastropy" or no top-level namespace (just the package name directly), until it's merged into the astropy core.

So this pull request is about the layout of the core package, and the astropy/project-template package is the one that is the template for affiliated packages. (it will reflect this design fairly closely so as to make merging easier, but will have slightly different names and include examples and such)

Once this layout is finalized, we will implement the affiliated package index, and it is those affiliated packages that will allow for the separate optional installable you have in mind.

While I see the advantages of the namespace package idea, they're a pain to use given the problems that PEP 382/402 were designed to fix. 382/402 are great, but we can't use them while still maintaing 2.x compatibility (they only apply to 3.2 and 3.3). So at least for the near term, this scheme is more straightforward.

I guess my problem is that it hasn't really been defined what make up the "core functionality" required for other Astronomy packages. By some definitions that could be a lot of stuff. But I'm fine with saying "no namespace packages" for now, and it can be worried about if "being too big" actually becomes a real problem.

You have a good point to keep in mind - we should definitely have this option on the radar for the future as we merge other affiliated packages in and be sure to at least allow for a change to a namespace package if "too big" becomes a problem. If nothing else, hopefully by then everyone will have moved to 3.x and we can safely use the 382/402 enhancements.

This looks good to me. Obviously the layout might still change slightly in future, but I think we should merge this for now.