[Distutils] install --dry-run broken?

[P.J. Eby]

At 09:03 AM 4/23/2010 +0200, Tarek Ziadé wrote:
>On Fri, Apr 23, 2010 at 6:58 AM, P.J. Eby <pje at telecommunity.com> wrote:
> > At 05:11 PM 4/22/2010 -0400, Jim Fulton wrote:
> >>
> >> Or maybe this constitutes "working" for distutils. ;)
> >
> > It does, I'm afraid.  The problem is that the build is also a dry run, so
> > the files aren't there for the later bits to actually copy.
> >
> > It might be better to do a dry run mechanism based mainly on setuptools'
> > sandboxing code -- the sandbox framework could be extended to allow faking
> > all file operations that go through normal Python APIs.  (i.e. not external
> > commands like compilers; those would of course fail unless separately
> > faked.)
>
>Right, I think sandboxing would be a better solution, less intrusive
>to the code,
>and this would work for *any* distutils command out there.
>
>Now my question is about setuptools' sandbox :  it seems to me that 
>it was only
>making sure a setup script wasn't trynig to write outside a given
>directory, using DirectorySandbox.
>
>1- How this tool could be used to record the writings ? Would we need
>to subtype AbstractSandbox ?
>2- If  1/ is doable, what about making this tool its own standalone
>project ? that would be useful for many projects

Yes, you'd need to make a subclass with an alternative policy 
mechanism.  One of the simplest ways might be to remap all the paths 
to a temporary subdirectory tree, except maybe for read-only access 
to files that don't yet exist in that tree.  (The advantage of using 
a temporary tree would be that non-Python code could potentially be 
pointed to real files.)

I'd be fine with making it available standalone.  The only reason 
it's bundled in setuptools is that setuptools needs to install from a 
single file; otherwise it would've had its own PyPI project from the beginning.