Automating build from source (was: Automating Sphinx generated documentation)

John Wong gokoproject at
Fri Sep 18 16:42:40 CEST 2015

On Fri, Sep 18, 2015 at 2:50 AM, Peter Otten <__peter__ at> wrote:

> Ben Finney wrote:
> > David Aldrich <David.Aldrich at EMEA.NEC.COM> writes:
> >
> >> I have setup Sphinx for my Python project. We keep all our code and
> >> documentation in Subversion.
> >
> > It's a good idea to keep *source* files in VCS.
> >
> > The VCS should track only those files that humans edit directly.
> Isn't this a case of purity versus practicality? I imagine it might be nice
> to get fairly up-to-date documentation along with your source code checkout
> "for free".

IMO, this is a decision an organization / individual has to make. But
nothing stops anybody from using branch (and tags in hg) to differentiate
pure source and pure build.

On Thu, Sep 17, 2015 at 9:54 PM, Grant Edwards <invalid at invalid.invalid>

> On 2015-09-17, Ben Finney <ben+python at> wrote:
> > The VCS should track only those files that humans edit directly.
> While I agree that files automatically generated shouldn't be checked
> in to a VCS, I'm in favor of putting key binary files under VCS if
> they are required to do the build.

if you are okay with cloning a huge repository then I don't see a problem.
You could have a separate repository for binary data, after VCS is just a
software implements some smart versioning of an object in some format
stored on somewhere.

I know of no convenient mechanism to reduce size of my .git or my .hg once
I committed my binary in my history. What I would do is provide the script
a URL where you can get your files. Imagine infrastructure as code, I can't
commit my oracle jdk/jre file all the time. I have a huge infrastructure to
manage and it would be GBs to clone. It happened to me once and I regret it.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Python-list mailing list