At 09:03 AM 4/23/2010 +0200, Tarek Ziadé wrote:
On Fri, Apr 23, 2010 at 6:58 AM, P.J. Eby <[email protected]> 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.
_______________________________________________
Distutils-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/distutils-sig
