-
-
Notifications
You must be signed in to change notification settings - Fork 42
Initial implementation of astropy_helpers #1
Conversation
…lpers and version_helpers modules from astropy; these are still heavily reliant on Astropy to work
…ule, mainly by copying over a few utility functions (some of these utilities are no longer used in astropy as a result--should we remove them?) Also removed any support for the astropy test and configuration frameworks, but that can be added back in later as needed...
…rs module. This enabled creating a version of generate_version_py that can work without having Astropy or any other support libraries installed, and that also provides support for projects that don't use git (though they lose revision numbers in their version strings until and unless we add support for other VCS (I do already have code to do this for SVN and HG should we wish to add it)).
… module; previously this was returning the version module in astropy_helpers itself. This changes the get_debug_option function such that it requires the package name. Will probably refactor functions like that into a class that is already instatiated with basic info about the package being built, such as its name.
…t won't work with astropy_helpers in its current state. This can, and should be revisited once we have a better idea of what we're going to do about configuration.
…as well just used the dashed name explcitly
…rs in the body of the with statement, restore sys.stdout/err so that the exception is displayed properly. Also add a dummy flush method to _DummyFile as there is some code in distutils that calls sys.stdout.flush
…works similarly to setuptool' ez_setup.py in how it tries several different routes to find the astropy_helpers module and get it on sys.path. The default is to just import it from a submodule called astropy_helpers--this is the default that will be used when running the astropy repo, for example. But there are many other options. I've tested out all the major use cases, but once I add a test suite to astropy_helpers it will be nice to have tests for the boostrap script as well.
@@ -0,0 +1,1558 @@ | |||
# Licensed under a 3-clause BSD style license - see LICENSE.rst |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I intend to do some further refactoring of this module and break it up into some smaller modules. I also intend to reduce the amount of "boilerplate" that needs to be added to setup.py for all the features in here to work. I've already started a little of that work in a local branch.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good - that file was indeed getting a bit large!
@embray - thanks for all your work on this! |
@embray - I know we are starting with the bare minimum, but wondering whether |
That might not be bad to move over either. Though I thinking in the long-term of moving away from zest.releaser. It's served me quite well, and I will probably continue to use it for many simpler projects. But the release process for Astropy has grown complex enough that I feel it would be difficult to fit within zest.releaser's framework, as it doesn't give quite enough control over the order in which certain things happen. I've been teasing myself with the idea of building up a release procedure using fabric. It would also start up a fresh copy of some standard VM for doing releases on, rather that doing releases directly from our desktop machines, so as to greatly improve reproducibility of releases. That's all long-term though. In the short-term |
Selfishly, it might be useful, as development progresses, to tag any area of the code that is Astropy specific (excepting grepable things). From a not-selfish perspective, it might help find areas that can be thought about more carefully. (To make this less out of the blue, this references an offline conversation with @embray about turning this into a more general package at some point.) |
# earler versions of git returned 0 even if the requested submodule | ||
# does not exist | ||
log.debug('git submodule command failed ' | ||
'unexpectedly:\n{0}'.format(sterr)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typo - should be stderr
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops.
…tus. It appears that in some versions of git even a successful run can output some text to stderr; see astropy/astropy#1563 (comment)
…mber of needed 'bootstrap' scripts :)
… using __file__ may have made sense when this was used primarily by Astropy itself, but in the context of an affiliated package it makes no sense.
…tropy_helpers.tests--this will allow us to use the package template itself as our test project for testing astropy_helpers :)
…rom sdists to keep those small. Running the astropy_helpers tests should be of interest to developers only for now. Also make sure the testpackage isn't recursed into for py.test since we don't want to run *its* tests
…h a bug which was fixed in c3f841b
…' sandboxing--this way we can capture test coverage properly
@embray - if I got to the directory where the git command is being run, I get:
weird, eh? |
@embray - this might help explain it:
(because we aren't actually in a sub-directory of astropy_helpers) |
The interesting thing is, why are you not seeing this error locally? In my case, it's working in a temporary directory that is no longer inside the astropy_helpers folder, so maybe it's something to do with that. |
…ate the test failure on Travis
That's for investigating this. That should help. I'll take a closer look... |
Okay, I understand what's going on here now. I'm still on git 1.7.5.x. In 1.7.8 they changed how the .git dir for submodules is handled. Instead it puts the .git dir contents for submodules under the top level repo's .git/, as The I think this would be resolved if, instead of doing a |
… to ensure the copy of package_template remains a valid git repo
Ah, Python 3 support is broken in the sphinxexts. We never did de-2to3 them I don't think. Well that should be easy. So...close now... |
Aha, the tox.ini doesn't install Sphinx. That's why I was missing those tests when I ran them locally. |
…d Python3.4 as well, and support for passing extra positional arguments to py.test
…aven't tested building actual docs with them yet.
@embray - how do you want to proceed once the tests pass? Shall we merge this, then later update the submodule URL once we merge in the package template changes? |
@embray - thanks for all your work on this! |
this |
🎊It passed!🎊 |
Took for bloody ever too. Travis gets busy on a Friday afternoon 😦 |
Initial implementation of astropy_helpers
Awesome! 🎆 - ironic that the tests themselves are so fast but it takes several hours to run them. |
Adding local python3 inv fix
switch to checking decoded version for build success message
Initial implementation of astropy_helpers
Initial implementation of astropy_helpers
Initial implementation of astropy_helpers
Initial implementation of astropy_helpers
Initial implementation of astropy_helpers
This starts to add the important pieces of astropy_helpers. It ports
astropy.version_helpers
andastropy.setup_helpers
into the new package and modifies them to work in the new context, without access to theastropy
package itself.It also adds some initial infrastructure such as the
ah_bootstrap.py
script that other packages will use to bootstrap astropy_helpers when using it.This should serve as an initial reference implementation for use with the first draft of the astropy_helpers APE. Rather than clone my fork of this directly, check out the pull request in astropy/astropy#1563. The branch I based that pull request off of pulls in this version of astropy_helpers (from my fork) as a submodule.