Skip to content
This repository has been archived by the owner on Nov 11, 2024. It is now read-only.

Initial implementation of astropy_helpers #1

Merged
merged 72 commits into from
May 16, 2014
Merged

Conversation

embray
Copy link
Member

@embray embray commented Dec 16, 2013

This starts to add the important pieces of astropy_helpers. It ports astropy.version_helpers and astropy.setup_helpers into the new package and modifies them to work in the new context, without access to the astropy 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.

…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.
…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
Copy link
Member Author

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.

Copy link
Member

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!

@astrofrog
Copy link
Member

@embray - thanks for all your work on this!

@astrofrog
Copy link
Member

@embray - I know we are starting with the bare minimum, but wondering whether astropy.utils.release should be one of the next helpers to get moved over to this package?

@embray
Copy link
Member Author

embray commented Dec 17, 2013

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 astropy.utils.release does seem like it could go into astropy_helpers.

@rhewett
Copy link

rhewett commented Dec 17, 2013

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))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo - should be stderr

Copy link
Member Author

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)
… 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
…' sandboxing--this way we can capture test coverage properly
@astrofrog
Copy link
Member

@embray - if I got to the directory where the git command is being run, I get:

mac-robitaille2:package_template tom$ pwd
/private/var/folders/zy/t1l3sx310d3d6p0kyxqzlrnr0000gr/T/pytest-52/test_update_git_devstr0/package_template
mac-robitaille2:package_template tom$ ls
MANIFEST.in     ah_bootstrap.py cextern         ez_setup.py     packagename     setup.cfg       temp
README.rst      astropy_helpers docs            licenses        scripts         setup.py
mac-robitaille2:package_template tom$ git rev-parse HEAD
fatal: Not a git repository: ../../../.git/modules/astropy_helpers/tests/package_template
mac-robitaille2:package_template tom$ git log
fatal: Not a git repository: ../../../.git/modules/astropy_helpers/tests/package_template

weird, eh?

@astrofrog
Copy link
Member

@embray - this might help explain it:

mac-robitaille2:package_template tom$ more .git
gitdir: ../../../.git/modules/astropy_helpers/tests/package_template

(because we aren't actually in a sub-directory of astropy_helpers)

@astrofrog
Copy link
Member

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.

@embray
Copy link
Member Author

embray commented May 16, 2014

That's for investigating this. That should help. I'll take a closer look...

@embray
Copy link
Member Author

embray commented May 16, 2014

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 ./git/modules/<submodule_name> as you posted above.

The .git for the submodule itself is just a plain file containing directives for where to find the actual .git dir.

I think this would be resolved if, instead of doing a shutil.copy of the package_template repo I just do a git clone of it. Let's give that a shot.

… to ensure the copy of package_template remains a valid git repo
@embray
Copy link
Member Author

embray commented May 16, 2014

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...

@embray
Copy link
Member Author

embray commented May 16, 2014

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.
@astrofrog
Copy link
Member

@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?

@astrofrog
Copy link
Member

@embray - thanks for all your work on this!

@embray
Copy link
Member Author

embray commented May 16, 2014

Shall we merge this, then later update the submodule URL once we merge in the package template changes?

this

@embray
Copy link
Member Author

embray commented May 16, 2014

🎊It passed!🎊

@embray
Copy link
Member Author

embray commented May 16, 2014

Took for bloody ever too. Travis gets busy on a Friday afternoon 😦

embray added a commit that referenced this pull request May 16, 2014
Initial implementation of astropy_helpers
@embray embray merged commit dda4407 into astropy:master May 16, 2014
@astrofrog
Copy link
Member

Awesome! 🎆 - ironic that the tests themselves are so fast but it takes several hours to run them.

astrofrog pushed a commit that referenced this pull request Jun 2, 2014
eteq pushed a commit that referenced this pull request Apr 15, 2016
switch to checking decoded version for build success message
@astrofrog astrofrog modified the milestone: 0.4.0 Jun 2, 2016
astrofrog pushed a commit to astropy/astropy-sphinx-theme that referenced this pull request Jan 20, 2018
Initial implementation of astropy_helpers
astrofrog pushed a commit to astropy/astropy-sphinx-theme that referenced this pull request Jan 24, 2018
Initial implementation of astropy_helpers
astrofrog pushed a commit to astropy/sphinx-automodapi that referenced this pull request Jan 27, 2018
Initial implementation of astropy_helpers
astrofrog pushed a commit to astropy/sphinx-automodapi that referenced this pull request Jan 27, 2018
Initial implementation of astropy_helpers
astrofrog pushed a commit to astropy/sphinx-astropy that referenced this pull request Jan 29, 2018
Initial implementation of astropy_helpers
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants