1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
|
# -*- org -*-
* github tarballs
** when downloaded from the "tags" page, look like:
warner-python-ed25519-0.4-0-gdeb78a0.tar.gz
** and unpack into:
warner-python-ed25519-deb78a0/
** That's a bummer, I was hoping they'd be like "python-ed25519-0.4.tar.gz"
and unpack into python-ed25519-0.4/ .
* git attributes --help:
add .gitattributes, with "_version.py export-subst"
then put $Format:XXX$ in the file, with XXX from git-log's --pretty=format:
$Format:%H$ -> commit hash
%h -> abbreviated commit hash
%d -> ref names, like git log --decorate
also "filename export-ignore": won't be added to an archive
might be possible to get github's 'git archive' to put the tag name into a
_version.py file
* first attempt at a plan:
** in the source tree
- commit a _version.py with a s="$Format:%d$" and some massaging code
- need to parse, strip boring refs, return highest non-boring one
** when using archive from github
- __init__.py pulls massaged string from _version.py
** when building from checkout for testing
- 'setup.py build' does git-describe and replaces _version.py with a
one-line variable set
- trouble: modifying a committed file, VCS will complain
- avoid by subclassing 'build', only modify build/lib../../_version.py
** when building sdist from checkout
- 'setup.py sdist' does git-describe and replaces _version.py
- less trouble with modifying a committed file, if we always do sdist from
a clean checkout (which is probably a good idea anyways)
** when running from source from checkout
- ?? need to do git-describe from _version.py, eww
** problems:
*** modifying _version.py during 'setup.py build' (for testing), leaves tree
in modified state, and you don't want to accidentally replace that
_version.py
*** really we want to modify a file in build/, not in the source tree
- might be possible for 'setup.py build', since we can get control after
the superclass method has run
- 'setup.py build' uses distutils.command.build_py
build_py.build_module to copy things into the build directory, can
use to figure out the _version.py to modify. Check for hardlinks. Hm,
looks like build doesn't use hardlinks, although sdist does.
- probably not so possible for 'setup.py sdist'. But maybe that's ok.
- actually, cmd.sub_commands=[] is a list of (name,runp) that are
invoked after self.filelist is created (but not populated), could be
used to invoke extra commands
- self.make_release_tree() is what creates the tree that will be
archived.. could override that, modify _version.py on the way out
- good to know: make_release_tree() creates hardlinks if possible. If
'setup.py build' does this too, that would explain why it's not
always necessary to rebuild when source files are changed.
- need to ensure _version.py is not a link before changing it
- make_release_tree(base_dir, files) creates os.path.join(base_dir,f)
for f in files
**** let's investigate this:
- 'setup.py build' runs superclass, looks for .git, if present:
- use git-describe
- locate build/STUFF/../_version.py
- replace it with one-line string variable set
- if no .git, assume the version number is already good, leave it alone
- 'setup.py sdist' looks for .git first, modifies _version.py in source
tree, then runs superclass
*** could modify a different file, one which is in .gitignore
- _version.py will need to import that
*** setup.py build
* current problems
** DONE running 'setup.py build' from a git-archive tree
- need version_from_expanded_variable() in versioneer.py too, not just
_version.py
|
