Simplify package-template usage #41
Conversation
|
This requires only a minor change to astropy itself, in astropy/astropy#2198, and that's only to make coverage work (which was a very recent ability to begin with). |
|
An open question here is how to transition existing affiliated packages to this new approach. I don't think there's any good way to automate that. The real benefit here is for newly created affiliated packages. @embray: You might also want to look at this in light of your work on the astropy setup tools package. I don't think the this steps on the toes of that, but there's always unintended consequences... |
|
Incidentally I was just about to go back to work on finishing that up. I also had some plans in mind to simplify things from the package-template end of things, but I'll take a look at what you've done so far. Chances are we're thinking along the same lines. I actually started something like this earlier but put it aside to focus more just on getting the astropy-distutils stuff working. |
|
At first I wasn't sure, but I like the idea of moving all the crud from |
| license = BSD | ||
| url = http://astropy.org/ | ||
| edit_on_github = False | ||
| github_project = astropy/astropy |
There was a problem hiding this comment.
So, something I was thinking of working toward eventually was switching Astropy over to using d2to1 or something like it. As I wrote in that e-mail this morning d2to1 still needs some love and care before it can really take on the task. But once it's ready to, part of its functionality is to describe all the project's metadata in its setup.cfg, just like this. Most of the stuff we implement currently in setup.py would become setup hooks, all of which would have direct access to this metadata as a dict.
There was a problem hiding this comment.
I was actually wondering that myself, as I looked into this. Maybe the thing to do for now is use the same variable names as d2to1 for the metadata (and put them in a [metadata] section), and put the other stuff (edit_on_github etc.) in another section. Then the future transition to d2to1 should be easier.
There was a problem hiding this comment.
You could put the non-standard stuff under [metadata] too--there's no harm there. But yes, let's go ahead and call this section [metadata] in the eventuality that we do make such a transition (and even if we don't I think it's clearer).
|
|
||
| git fetch template | ||
| git fetch upstream | ||
| # Make your master match the upstream master. This will destroy |
There was a problem hiding this comment.
Can you insert a space above this line?
|
@mdboom - this is a great idea, and I'm kicking myself for not having done this before ;) Is it ready to merge in your view? Once this is merged, I can send out an email to affiliated package maintainers. |
|
I think this is ready to merge. |
|
Any objections to merging? I have an affiliated package I'd like to start based on this 😉 |
| os.path.join( | ||
| os.path.relpath(root, PACKAGENAME), filename)) | ||
| package_info['package_data'][PACKAGENAME].extend(c_files) | ||
|
|
There was a problem hiding this comment.
Just out of curiosity, why is this needed?
There was a problem hiding this comment.
This replaces this line in MANIFEST.in:
recursive-include packagename *.pyx *.c
Without it, the c files that are generated from pyx files are not included in the tarball. I couldn't see any way to programmatically change what's in MANIFEST.in. I should add a longer comment about this, obviously.
There was a problem hiding this comment.
Ah, so the idea is that then you are not dependent on developers keeping that in the MANIFEST.in? I wonder whether this is not something that should instead be dealt with in the sdist command? (I think we already overload it?). For now, this is fine though.
There was a problem hiding this comment.
We don't override sdist -- we just opt out of setuptools sdist and use distutils sdist instead. Oh, the joys of Python packaging 😉
I agree this isn't ideal, but I was also trying to not require changes to astropy (except for one change for coverage, which was broken in all released astropy's anyway).
There was a problem hiding this comment.
No problem - once we have astropy-helpers, then I suggest we create a custom sdist command and deal with that there. For now, this is good.
There was a problem hiding this comment.
Technically this can be done with a setuptools.file_finders entry point without even having to muck around with subclassing or anything of the like.
|
@mdboom - I have no objections to merging, just a question above |
|
@mdboom - thanks! Merging :) |
Simplify package-template usage
|
@mdboom - I really like the new infrastructure, but just one small question. In APLpy, we distinguish between the 'human'-readable package name (APLpy) and the name of the python package (aplpy). Can we add a new option in |
|
Where do you use one vs. the other? |
|
The only place we use the 'human-readable' name is for because that's what's used for the sdist command for example. For all other |
This reduces the amount of changes necessary to customize the
package-templatefor a new affiliated package.It basically amounts to:
setup.cfgThe important benefit of this is not that it takes less time to set up, but that this should make it easier to pull in changes to the
package-templatein the future. (And in that regard, we probably want to start tagging package-template releases with each astropy release, but that's for another PR...)