On 1/22/2010 4:38 PM, Tarek Ziadé wrote:
On Sat, Jan 23, 2010 at 1:15 AM, Sridhar Ratnakumar
wrote:
[..]
> Will this callable recieve TarInfo objects if the filetype is tarfile? What
> would it receive otherwise? How can `_ensure_read_write_access` be
> implemented using this callable? I ca
On Sat, Jan 23, 2010 at 1:15 AM, Sridhar Ratnakumar
wrote:
[..]
> Will this callable recieve TarInfo objects if the filetype is tarfile? What
> would it receive otherwise? How can `_ensure_read_write_access` be
> implemented using this callable? I cannot think of a design for this. (In
> that case
On 1/22/2010 3:19 PM, Tarek Ziadé wrote:
[..]
> How about having an extra argument that would fix the permission? (Fixing
> the permission is only applicable for tarfile, not zipfile, hence even our
> callable will become specific to tarfile).
>
>>>> shutil.unpack_archive("/tmp/foo.tgz",
[...]
> To give an example, what if when Distribute uses `shutil.unpack_archive` to
> unpack a sdist from PyPI (the author generated the archive with u-r,u-x set
> on files/directoreis -- I've seen this happening before), the subsequent
> "python setup.py install" would fail due to permission issue
On 1/22/2010 2:44 PM, Tarek Ziadé wrote:
On Fri, Jan 22, 2010 at 11:17 PM, Sridhar Ratnakumar
wrote:
[..]
> 3) Patch Lib/tarfile.py to fix issue6196
>
> I am hoping that (1) and (2) will get accepted. But not (3) - in which case,
> should this go as a workarond (_ensure_read_write_access in
On Fri, Jan 22, 2010 at 11:17 PM, Sridhar Ratnakumar
wrote:
[..]
> 3) Patch Lib/tarfile.py to fix issue6196
>
> I am hoping that (1) and (2) will get accepted. But not (3) - in which case,
> should this go as a workarond (_ensure_read_write_access in
> http://gist.github.com/279606) in the new, sa
On 1/17/2010 2:09 PM, Tarek Ziadé wrote:
> Distribute has
> some utility code to handle zip/tar archives. So does PyPM. This is because
> the `tarfile` and `zipfile` modules do not "just work" due to several
> issues.
>
> Seehttp://gist.github.com/279606
>
> Take note of the following in th
On Mon, Jan 18, 2010 at 1:21 AM, Tarek Ziadé wrote:
> Hello,
>
> For 2.7/3.2, I am in the process of removing modules in Distutils that
> can be replaced by calls to existing functions in stdlib. For
> instance, "dir_util" and "file_util" (old modules from the Python 1.x
> era) are going away in
Paul Moore wrote:
> 2010/1/18 R. David Murray :
>> So +1 from me for putting these in shutil.
>
> Conceptually, I'm happy with these going into shutil (and +1 on the
> rest of Tarek's proposal, too!)
>
> To my mind, shutil is a module for higher-level operations on files -
> the sort of things yo
2010/1/18 R. David Murray :
> On Mon, 18 Jan 2010 10:56:05 -0500, "Steve Steiner (listsin)"
> wrote:
>> As much of a pain as it is to get new modules accepted, I agree that
>> mixing archiving functions into shutil is not the right way to do it
>> and that a separate archive_util module would mak
On Mon, 18 Jan 2010 10:56:05 -0500, "Steve Steiner (listsin)"
wrote:
> As much of a pain as it is to get new modules accepted, I agree that
> mixing archiving functions into shutil is not the right way to do it
> and that a separate archive_util module would make much more sense and
> would give
On Jan 18, 2010, at 8:34 AM, Masklinn wrote:
> On 18 Jan 2010, at 13:40 , Nick Coghlan wrote:
>>
>> Tarek Ziadé wrote:
>>> There's one remaining external call for "zip" done if the zip module
>>> is not found, but I am happy to remove it and throw an exception if
>>> it's not found, and keep the
On Mon, Jan 18, 2010 at 3:56 PM, Masklinn wrote:
[..]
>> Well - isn't what's being proposed "a number of high-level operations on
>> files and collections of files." ?
>>
> Well no those are high-level operations on a very restricted set of file
> types (archives)
not really: make_archive/unpac
On Mon, Jan 18, 2010 at 02:34:14PM +0100, Masklinn wrote:
> Isn't it a bit weird to include that to shutil though? shutil advertises
> itself as "a number of high-level operations on files and collections of
> files." and from what I understood it was a bunch of shell-type utility
> functions to
On 18 Jan 2010, at 14:57 , Michael Foord wrote:
>
> On 18/01/2010 13:46, Doug Hellmann wrote:
>>
>> On Jan 18, 2010, at 8:34 AM, Masklinn wrote:
>>
>>> On 18 Jan 2010, at 13:40 , Nick Coghlan wrote:
Tarek Ziadé wrote:
> There's one remaining external call for "zip" done if the zip
On Mon, Jan 18, 2010 at 2:57 PM, Michael Foord
wrote:
[..]
>>> Wouldn't it make more sense to put those "archive utils"
>>> functions/objects in a new module separate from shutil, dealing specifically
>>> with cross-archive APIs and linked from the current archive-specific modules
>>> (essentially
On 18/01/2010 13:46, Doug Hellmann wrote:
On Jan 18, 2010, at 8:34 AM, Masklinn wrote:
On 18 Jan 2010, at 13:40 , Nick Coghlan wrote:
Tarek Ziadé wrote:
There's one remaining external call for "zip" done if the zip module
is not found, but I am happy to remove it and throw an exception if
i
On Jan 18, 2010, at 8:34 AM, Masklinn wrote:
On 18 Jan 2010, at 13:40 , Nick Coghlan wrote:
Tarek Ziadé wrote:
There's one remaining external call for "zip" done if the zip module
is not found, but I am happy to remove it and throw an exception if
it's not found, and keep the external "zip"
On 18 Jan 2010, at 13:40 , Nick Coghlan wrote:
>
> Tarek Ziadé wrote:
>> There's one remaining external call for "zip" done if the zip module
>> is not found, but I am happy to remove it and throw an exception if
>> it's not found, and keep the external "zip" call on Distutils side, so
>> shutil s
Tarek Ziadé wrote:
> There's one remaining external call for "zip" done if the zip module
> is not found, but I am happy to remove it and throw an exception if
> it's not found, and keep the external "zip" call on Distutils side, so
> shutil stays 100% stdlib-powered.
+1 for that approach. These c
On Sun, Jan 17, 2010 at 10:50 PM, Sridhar Ratnakumar
wrote:
[..]
> Will it also allow decompression of the said archive types?
No but it would make sense having this one as well.
Distribute/Setuptools' "unpack_archive" (used by easy_install) was
implemented using the same principle as Distutils'
On 1/17/2010 12:09 PM, Tarek Ziadé wrote:
On Sun, Jan 17, 2010 at 8:55 PM, Brett Cannon wrote:
> On Sun, Jan 17, 2010 at 11:51, Tarek Ziadé wrote:
>> Another module I would like to move away from Distutils is
>> "archive_util". It contains helpers to build archives, whether they
>> are zi
On Sun, Jan 17, 2010 at 9:15 PM, Michael Foord
wrote:
[..]
>> Are these functions portable? Do they rely on external programs?
>>
>>
>
> I believe that part of the work that Tarek has been doing has been to make
> these distutils commands use the Python standard library and not depend on
> externa
On 17/01/2010 20:04, Antoine Pitrou wrote:
Tarek Ziadé gmail.com> writes:
Another module I would like to move away from Distutils is
"archive_util". It contains helpers to build archives, whether they
are zip or tar files. I propose to move those useful functions into
shutil, as this seems
On Sun, Jan 17, 2010 at 8:55 PM, Brett Cannon wrote:
>
>
> On Sun, Jan 17, 2010 at 11:51, Tarek Ziadé wrote:
>>
>> Hello,
>>
>> For 2.7/3.2, I am in the process of removing modules in Distutils that
>> can be replaced by calls to existing functions in stdlib. For
>> instance, "dir_util" and "file
Tarek Ziadé gmail.com> writes:
>
> Another module I would like to move away from Distutils is
> "archive_util". It contains helpers to build archives, whether they
> are zip or tar files. I propose to move those useful functions into
> shutil, as this seems the most logical place.
Are these func
On Sun, Jan 17, 2010 at 11:51, Tarek Ziadé wrote:
> Hello,
>
> For 2.7/3.2, I am in the process of removing modules in Distutils that
> can be replaced by calls to existing functions in stdlib. For
> instance, "dir_util" and "file_util" (old modules from the Python 1.x
> era) are going away in fa
On 17/01/2010 19:51, Tarek Ziadé wrote:
Hello,
For 2.7/3.2, I am in the process of removing modules in Distutils that
can be replaced by calls to existing functions in stdlib. For
instance, "dir_util" and "file_util" (old modules from the Python 1.x
era) are going away in favor of calls to shuti
28 matches
Mail list logo
