nches/tarek_sysconfig/Lib/sysconfig.py?content-type=text%2Fplain
I've refactored distutils/ and site.py so they work with this new
module, and added deprecation warnings in distutils.sysconfig.
All tests pass in the branch, but note that the code is still u
On Sat, Dec 12, 2009 at 10:35 PM, Brett Cannon wrote:
[...]
>> 'nt': {
>> 'stdlib': '$base/Lib',
>> 'platstdlib': '$base/Lib',
>> 'purelib': '$base/Lib/site-packages',
>> 'platlib': '$base/Lib/site-packages',
>> 'include': '$base/include',
>> 'platinclude
On Sat, Dec 12, 2009 at 11:18 PM, Brett Cannon wrote:
[..]
>> Not really. That's mostly because I reused the existing implementation
>> and I found them quite readable in that case. But a string.Formatter
>> could work well here too I guess.
>
> Just figured that with formatters the way of the fut
On Sun, Dec 13, 2009 at 9:53 AM, Ben Finney wrote:
> Tarek Ziadé writes:
>
>> I've started to add another section in the PEP to summarize this
>> discussion but then I realized that we are already giving the answer
>> in the PEP in the "Requisites and curre
On Fri, Dec 11, 2009 at 11:23 AM, Nick Coghlan wrote:
[..]
>
> Eric's suggestion of NormalizedVersion sounds best to me - it exactly
> describes the intended role of the class.
>
Done. Steve Steiner added a nice functional test that tries the scheme
on *all* pypi versions:
MacZiade:distutilsver
On Mon, Dec 14, 2009 at 10:52 AM, M.-A. Lemburg wrote:
[..]
>> I've refactored distutils/ and site.py so they work with this new
>> module, and added deprecation warnings in distutils.sysconfig.
>
> I think we really need to do something about these kinds of
> deprecations.
>
> IMHO, there is no n
eturn values. For example in
> IronPython the minimal thing we'd want I think is a "cli" directory for
> .NET assemblies. But there could also be native extensions which are
> platform specific so we'd want "cli-x86" and "cli-x64" depending u
On Tue, Dec 15, 2009 at 1:00 AM, Dino Viehland wrote:
[..]
> How would you know what other architectures would be valid to pass in
> here? Returning a list would let the implementation say that it knows
> a certain set of architectural binaries are valid.
How would you use it when a list is retu
On Tue, Dec 15, 2009 at 5:12 AM, Ben Finney wrote:
[..]
>
>> > I don't think they belong in this PEP; they are a property of the OS
>> > install/version, not of the specific Python install/version.
>
> I think the “sysconfig” specification should allow for *extension*,
> without needing a modified
that - it just jumped
> out at me because IronPython and Jython do have multiple platforms
> which could be relevant at one time.
Sure, and that's why I have asked feedback from IrontPython/Jython people,
Thanks for that.
Regards
Tarek
--
Tarek Ziadé | http://ziade.org
__
On Sun, Dec 13, 2009 at 12:56 PM, Tarek Ziadé wrote:
[..]
>
> Furthermore, I've seen some patterns in those 5% that can be worked
> out so I'll probably be able to lower it to 3%
Done:
Total Packages : 8690
Already Match : 7645.0 (87.97%)
Have Suggestion : 768.0 (8
p, a
standalone version of Distutils for 2.6/2.5, etc..) to get ready to
support them by the time 2.7 final is out.
Regards
Tarek
--
Tarek Ziadé | http://ziade.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/list
hing to inform about that API in the PEP I guess,
>> Finally, as a general formatting request - some blank space between the
>> end of the previous example and the header for the next field
>> description would make the field descriptions much easier to read.
>
> Hmm
On Wed, Dec 23, 2009 at 11:18 AM, Tarek Ziadé wrote:
[..]
>
> if a "1.2" field is found and no "1.1" field is found:
> metadata 1.2 is used
> if a "1.1" field is found and no "1.2" field is found:
> metadata 1.1 is used + a warning is
2009/12/23 "Martin v. Löwis" :
>> The deprecation of the existing Requires/Provides/Obsoletes fields
>> should be more prominent - tucked away below the examples, I missed
>> these notices on the first read through (I only noticed that they
>> actually had been formally deprecated when I got to the
incompatible with existing consumers that expect
> a Python package to have an earlier version of the metadata.
> Dropping 1.0 may be fine though - but again, this is out of scope
> here.
I don't understand why you are saying this is out of scope. Shouldn't we
state cle
flict. If the reference implementation
> is right, implementers of the PEP would *also* need to study the
> reference implementation to find out what conforming behaviour is.
>
> This is bad; the PEP should be the only definition of the metadata
> format.
Ok, I'll remove that part.
On Thu, Dec 24, 2009 at 10:26 AM, "Martin v. Löwis" wrote:
> David Lyon wrote:
>> On Thu, 24 Dec 2009 10:31:09 +0900, "Stephen J. Turnbull"
>> wrote:
>>
>>> Martin's point is that the PEP process doesn't *have* "reference"
>>> implementations. It has *sample* implementations. It may be useful
>
On Fri, Dec 25, 2009 at 8:33 AM, Nick Coghlan wrote:
> Martin v. Löwis wrote:
>>> I'll remove it and push it in Distutils documentation, then might just
>>> provide a link in the PEP References.
>>
>> That sounds fine to me.
>
> That would address my questions as well - someone looking for a guide
On Mon, Dec 28, 2009 at 1:15 AM, wrote:
>> On Fri, Dec 25, 2009 at 8:33 AM, Nick Coghlan wrote:
>>> Martin v. Löwis wrote:
>> FYI we have introduced a range operator, so one may define a range of
>> versions.
>> This is useful for instance to write:
>>
>> Requires-Python: ~=2.5
>>
>> Which mea
that is inferior or equal to 2.5.0 so 2.5.4
doesn't match
>
> Also, "Requires-Python: 3" would include all 3.X versions, correct?
Correct, because, "Requires-Python: 3" is equivalent to "Requires-Python: ~= 3"
which is equivalent t
On Mon, Dec 28, 2009 at 1:48 AM, Antoine Pitrou wrote:
> Tarek Ziadé gmail.com> writes:
>>
>> This was ambiguous because it was unclear, as MvL stated, if "2.5"
>> was just "2.5.0" or included
>> versions like "2.5.1" or "2.5.2&
n't matter
if a software doesn't use the .0
Tarek
--
Tarek Ziadé | http://ziade.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Mon, Dec 28, 2009 at 6:20 AM, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Tarek Ziadé wrote:
>> On Mon, Dec 28, 2009 at 1:41 AM, Sridhar Ratnakumar
>> wrote:
>> [..]
>>> Tarek,
>>>
>>> I am a bit
On Mon, Dec 28, 2009 at 6:16 AM, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Terry Reedy wrote:
>> On 12/27/2009 7:48 PM, Antoine Pitrou wrote:
>>> Tarek Ziadé gmail.com> writes:
>>>> This was ambiguous because it was uncle
On Mon, Dec 28, 2009 at 3:03 AM, MRAB wrote:
> Martin v. Löwis wrote:
>>>
>>> No application developer will quickly figure out what a tilde means.
>>> Maybe
>>> it means 'roughly', but it requires too much thought and is ambiguous.
>>> 2.5
>>> is not roughly 2.5.2. It is the same exactly.
>>>
>>>
On Mon, Dec 28, 2009 at 4:17 AM, Stephen J. Turnbull wrote:
> Ben Finney writes:
>
> > Instead, the default should be `=='. That is, `Requires-Python: 3'
> > should be equivalent to `Requires-Python: ==3'; and only "3" or "3.0" or
> > "3.0.0" etc. will match. I maintain that is what most people
quot;, either "2.5.0". And it seems to me that in
the common usage, it means "2.5.x".
If we agree on this, then Antoine's proposal seems like the natural solution.
Regards,
Tarek
--
Tarek Ziadé | http://ziade.org
___
Python-De
2009/12/28 "Martin v. Löwis" :
>> I think Antoine's proposal is good (using the range when "2.5" is
>> used, and using 2.5.0 when explicitely
>> needed), and fixes Martin's concerns.
>>
>> So I would be in favor of removing ~= and using Antoine's rule;
>
> So specifying 2.5 would be a short-hand fo
he PEP already works with your
examples, and is way less complex that your proposals I think.
Regards
Tarek
--
Tarek Ziadé | http://ziade.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsub
2009/12/28 "Martin v. Löwis" :
[..]
>> 2.5.0 would be the notation required to describe this specific micro version.
>
> I think it would be a shorthand for >=2.5.0, <2.5.1, right?
>
> Or are you saying that specifying a version is sometimes a shorthand for
> a range, and sometimes a shorthand for
And if not, is subject to errors by forgetting dashes or dots.
Regards,
Tarek
--
Tarek Ziadé | http://ziade.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Mon, Dec 28, 2009 at 12:04 PM, Lennart Regebro wrote:
> On Mon, Dec 28, 2009 at 12:02, Tarek Ziadé wrote:
>> -1. This looks like typos the developer made on his versions definitions.
>
> Nah.
>
>> And if not, is subject to errors by forgetting dashes or dots.
>
&
On Mon, Dec 28, 2009 at 12:02 PM, Lennart Regebro wrote:
> On Mon, Dec 28, 2009 at 11:54, "Martin v. Löwis" wrote:
>> This == operator is fairly common in Debian. For example, the apache2
>> package installed on my system specifies
>
> Oh, absolutely, but that's when you specify interdependencies
On Mon, Dec 28, 2009 at 9:26 PM, Tres Seaver wrote:
[..]
>> Requires-Dist: zope.interface (3.1.0) ==> only 3.1.0
>
> For completeness, isn't this really "any versino which starts with
> 3.1.0, not including post- or pre- releases"? That particular pacakge
> doesn't use more than a third version
On Tue, Dec 29, 2009 at 2:17 AM, sstein...@gmail.com
wrote:
>
> On Dec 28, 2009, at 8:00 PM, Ben Finney wrote:
>
>> The dependency declarations are *not* Python language syntax, and there
>> is no need to consider Python language syntax in defining them.
>
> Agreed.
>
> We're also not going to be
le who use
> both Python and Jython per-user installation.
Right, good idea
Tarek
--
Tarek Ziadé | http://ziade.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Sat, Dec 12, 2009 at 9:02 PM, Tarek Ziadé wrote:
> Hello,
>
> A while ago I've proposed to refactor the APIs that provides access to
> the installation paths and configuration variables at runtime into a
> single module called "sysconfig", and make it easier for
ects, from PEP 386 point of view.
Is there anything else I can do to make those two PEPs accepted ?
Regards
Tarek
--
Tarek Ziadé | http://ziade.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
reciated. Particularly reviewing new and
> outstanding issues.
Another useful triage I think, is to review the oldest bugs (some of
them are > 5 years)
and remove the ones that are not relevant anymore, or duplicate with
newer entries.
Tarek
--
Tarek Ziadé | http://ziade.org
_
On Wed, Jan 6, 2010 at 1:31 PM, Chris Withers wrote:
> Tarek Ziadé wrote:
>>
>> Another useful triage I think, is to review the oldest bugs (some of
>> them are > 5 years)
>> and remove the ones that are not relevant anymore, or duplicate with
>> newer entr
On Thu, Jan 14, 2010 at 10:23 AM, Vinay Sajip wrote:
[..]
> So, can you please indicate your vote for or against incorporating PEP 391
> into Python? It would
> be nice if I could incorporate the changes before 2.7a3 is released! Ideally,
> I would like to check
> in the changes unless there are
maintain this "shutil" module for now on (no one is
declared as a maintainer in maintainers.rst) since Distutils will
become a heavy user of its functions.
Any objections/opinions ?
Regards,
Tarek
--
Tarek Ziadé | http://ziade.org
___
Pytho
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
x27;s not found, and keep the external "zip" call on Distutils side, so
shutil stays 100% stdlib-powered.
> Of course Tarek can speak for himself...
Thanks for explaining it ! :)
Regards
Tarek
--
Tarek Ziadé | http://ziade.org
___
Pytho
gt; 5) TarredFile.extract ... issue 6584
Looks like some of these are already fixed (I just looked quickly in
the bug tracker though)
If its not already done and pending, it would be great if you could
refactor your fixes into patches for the remaining is
for this new API.
We could even add references in the tarfile, zipfile modules
documentation pointing to these examples.
Regards
Tarek
--
Tarek Ziadé | http://ziade.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listi
king with archives is just a target like another I
think.
But at the end I am 0- to create a new module, because what really
matters to me is to take it out of Distutils :)
Regards,
Tarek
--
Tarek Ziadé | http://ziade.org
___
Python-Dev mailing list
lled with each newly extracted file, so one may apply
any process on it.
Regards,
Tarek
--
Tarek Ziadé | http://ziade.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python
That's still the same specific use case. Out of curiosity, how many
archives have you had the
problem with ?
If like I think, this is quite rare, I am -1 to introduce it that way
because you could handle with a generic callable as mentioned.
Regards
Tarek
--
Tarek Ziadé | htt
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
all three PEPs will be
> accepted in time for inclusion in Python 2.7.
We will work on 376 in the two coming weeks in distutils-SIG and try
to come up with
something ready for Pycon, if feasible.
Thanks for the reviews !
Tarek
--
Tarek Ziadé | http://ziade.org
pi/keyring
Regards
Tarek
--
Tarek Ziadé | http://ziade.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Wed, Feb 10, 2010 at 12:29 AM, Guido van Rossum wrote:
[..]
>
> Since this is done I now approve both PEP 345 and PEP 386 (which is
> not to say that small editorial changes to the text couldn't be made).
Thanks !
Thanks to all the people that helped in those PEPs
Tarek
_
Hello Dirkjan,
We are going to start working on a few things in Distutils at Pycon
outside the trunk.
I was about to start this work in the svn sandbox, but if possible I'd
rather have a repo at hg.python.org as well
Regards
Tarek
--
Tarek Ziadé | http://ziad
On Sun, Feb 21, 2010 at 9:47 PM, Dirkjan Ochtman wrote:
> On Sun, Feb 21, 2010 at 21:44, Tarek Ziadé wrote:
>> We are going to start working on a few things in Distutils at Pycon
>> outside the trunk.
>
> This would be full branch of Python? In that case, we probably don
On Sun, Feb 21, 2010 at 10:54 PM, Dirkjan Ochtman wrote:
> On Sun, Feb 21, 2010 at 21:56, Tarek Ziadé wrote:
>> No that would be just a new fresh empty repository for "distutils 2"
>> that will be developed outside the Python stdlib for a while, and will
>> enventu
On Mon, Feb 22, 2010 at 12:04 PM, Dirkjan Ochtman wrote:
> On Sun, Feb 21, 2010 at 23:15, Tarek Ziadé wrote:
>> Sounds good, thanks
>
> It's right here: ssh://h...@hg.python.org/repos/distutils2
Thanks a lot
___
Python-Dev mai
ns, so I think we need to have the same policy
here if possible, and use for example a subject prefix to make the
filtering easier (which should be simpler with multiple mercurial
repositories as a matter of fact)
Tarek
--
Tarek Ziadé | http://ziade.org
___
2010/2/23 Dirkjan Ochtman :
> 2010/2/23 Tarek Ziadé :
>> Why is that ? I do want them as much as someone else would want the
>> benchmarks ones I suppose.
>>
>> The whole subversion repository (including the sandbox) is sending
>> mails to python-checkins, so
2010/2/23 Dirkjan Ochtman :
> 2010/2/23 Tarek Ziadé :
>> Note sure what do you mean by doubts. I have no doubts I want to
>> receive those emails to work on this code ;)
>
> Some of the other committers didn't think they wanted email on
> python-checkins from all t
On Tue, Feb 23, 2010 at 1:50 PM, Maciej Fijalkowski wrote:
> Hello.
>
> I would like to have a feature on platform module (or sys or
> somewhere) that can tell distutils or distutils2 that this platform
> (be it PyPy or Jython) is not able to compile any C module. The
> purpose of this is to make
,
so your project still installs.
That's basically what people now can use when they have a pure Python
fallback version they
want to provide in case the C version cannot be built for any reason.
Tarek
--
Tarek Ziadé | http://ziade.org
___
Pytho
On Tue, Feb 23, 2010 at 2:10 PM, Tarek Ziadé wrote:
> On Tue, Feb 23, 2010 at 1:50 PM, Maciej Fijalkowski wrote:
>> Hello.
>>
>> I would like to have a feature on platform module (or sys or
>> somewhere) that can tell distutils or distutils2 that this platform
>&
On Tue, Feb 23, 2010 at 2:44 PM, Maciej Fijalkowski wrote:
> On Tue, Feb 23, 2010 at 2:27 PM, Tarek Ziadé wrote:
>> On Tue, Feb 23, 2010 at 2:10 PM, Tarek Ziadé wrote:
>>> On Tue, Feb 23, 2010 at 1:50 PM, Maciej Fijalkowski
>>> wrote:
>>>> Hello.
>
ponent,
so I can
start to reorganize the issues in there and reassign new issues to
Distutils2 when it applies.
Regards
Tarek
--
Tarek Ziadé | http://ziade.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/
On Fri, Feb 26, 2010 at 11:13 PM, Brett Cannon wrote:
[..]
> I assume you want the Distutils2 component to auto-assign to you like
> Distutils currently does? If so I can add the component for you if people
> don't object to the new component.
Sounds good -- Thanks
___
s welcome of course on any part.
As Terry suggested you can send a mail at Catalog, I'll catch up on
the thread once its started, to list possible tasks.
Regards,
Tarek
--
Tarek Ziadé | http://ziade.org
___
Python-Dev mailing list
Pyt
Just FYI : I am post-poning the revert of Distutils to 2.6.x right
after 2.7a4 has been tagged to avoid any problems (this is in 3 days)
The revert is ready but 3 days is not long enough to make sure
everything is going smooth.
On Fri, Feb 26, 2010 at 10:44 PM, Tarek Ziadé wrote:
> He
this feature on the top of distutils
(and distutils2 later I guess) and is not hard to install on the top
of Python.
But the "auto-update" story seems interesting, can you expand on this ?
Tarek
--
Tarek Ziadé | http://ziade.org
___
Python-
On Wed, Mar 24, 2010 at 12:20 PM, anatoly techtonik wrote:
> On Wed, Mar 24, 2010 at 12:26 PM, Tarek Ziadé wrote:
>>
>> Distutils2 is planned to be reintegrated in the stdlib in Python 3.3,
>> and my goal is to release it when Python 2.7 final is released.
>
> Does th
On Wed, Mar 24, 2010 at 12:50 PM, Darren Dale wrote:
> On Wed, Mar 24, 2010 at 6:26 AM, Tarek Ziadé wrote:
>> The open question is: do we want to include a full installer that
>> takes care of installing / removing dependencies as well ?
>>
>> I think not. Pip alrea
ould need to do is propose an extension to
PEP 376, we are currently working
on, then we can add it there once people have discussed it on
distutils-SIG, or maybe create a new PEP if the topic is too big to
fit in 376.
>
>
> P.S. Please be careful to reply to re
tely its business.
> My vision is that decision about having bootstrap package or not in
> 2.7 should be in python-dev and specific packaging, implementation and
> pip/distutils/distribute questions in distutils-sig.
If the mentioned bootstrap script is about a package managment system
On Mon, Mar 29, 2010 at 11:15 AM, Tarek Ziadé wrote:
[..]
> Depending on how you call a Python user, I disagree here. Many people
> use pip and distribute.
s/how/who :)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyth
e a look in this
guide though, for guidance"
I still think you should remove python-dev from the cc list ;)
Tarek
--
Tarek Ziadé | http://ziade.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Anatoly, I am now answering only in Distutils-SIG.
On Mon, Mar 29, 2010 at 3:45 PM, anatoly techtonik wrote:
[..]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/m
uce another PEP for that, that will not interfer with PEP
376.
Regards
Tarek
--
Tarek Ziadé | http://ziade.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman
is.
> Anyway, that's my first pass through; I think the RECORD section may need
> further fleshing out (e.g., specifying a particular csv-module dialect) in
> order to ensure that the spec is sufficiently rigorous for multiple tools to
> consume/produce compatible files.
Yes, and we
tions that are not yet installed where these infos
are still hidden in setup.py.
Although we are currently working in distutils2 to get rid of setup.py
and have a pure static metadata file.
> On Apr 1, 2010, at 5:51 PM, Tarek Ziadé wrote:
>
> - to provide a basic *uninstaller* feature in
kages directory was not under sys.prefix, we would
use an absolute path for files under sys.prefix but not in
site-packages. (like rst2html.py)
Regards
Tarek
--
Tarek Ziadé | http://ziade.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.
On Wed, Apr 7, 2010 at 4:35 PM, P.J. Eby wrote:
> At 04:01 PM 4/7/2010 +0200, Tarek Ziadé wrote:
>>
>> 2010/4/2 P.J. Eby :
>> [...]
>> >
>> > * Paths under the base installation location are relative to the base
>> > * Paths not und
it in pkgutil for Python 3.2 and
provide a backport in distutils2. (In fact Michael Mulich has
started this work in distutils2, so it might be done the other way)
The next big piece is the FHS-compatible handling of resource files,
which will worth a PEP on its own.
Regards
Tarek
--
Tarek
2010/4/22 Eric Smith :
> Jeroen Ruigrok van der Werven wrote:
>>
>> -On [20100422 10:55], Tarek Ziadé (ziade.ta...@gmail.com) wrote:
>>>
>>> The next big piece is the FHS-compatible handling of resource files,
>>> which will worth a PEP on its own.
>
2010/4/22 P.J. Eby :
> At 10:54 AM 4/22/2010 +0200, Tarek Ziadé wrote:
>>
>> Hello,
>>
>> I think I went through all the latest feedback regarding PEP 376.
>>
>> There will be still some work of course, on the implementation side
>> (for instance the Zi
On Thu, Apr 22, 2010 at 6:05 PM, Tarek Ziadé wrote:
> 2010/4/22 P.J. Eby :
>> At 10:54 AM 4/22/2010 +0200, Tarek Ziadé wrote:
>>>
>>> Hello,
>>>
>>> I think I went through all the latest feedback regarding PEP 376.
>>>
>>> Ther
erly,
__file__ is what developer use when they need their projects to be portable..
Notice that we have started to work on fixing this -
http://hg.python.org/distutils2/file/tip/docs/design/wiki.rst
Tarek
--
Tarek Ziadé | http://ziade.org
___
Python-De
On Mon, Apr 26, 2010 at 10:10 PM, Piotr Ożarowski wrote:
> [Tarek Ziadé, 2010-04-26]
>> Great hints, I'll try to follow them... and they could make a good
>> section in the Hitchhiker's guide to packaging ;)
>
> How about these two:
> http://us.pycon.org
On Mon, Apr 26, 2010 at 11:45 PM, Barry Warsaw wrote:
[..]
>
> For example, there's a nice tool called 'Quickly' that builds application
> templates using best practices. It is opinionated, but designed for the
> opportunistic programmer. I've been thinking about writing a Python
> application a
On Mon, Apr 26, 2010 at 11:46 PM, Barry Warsaw wrote:
> On Apr 26, 2010, at 09:39 PM, Tarek Ziadé wrote:
>
>>You should be permissive on that one. Until we know how to describe resource
>>files properly, __file__ is what developer use when they need their projects
>>to
On Mon, Apr 26, 2010 at 11:56 PM, Robert Kern wrote:
[..]
>
> I don't think the OP is really speaking against using __file__ per se, but
> rather putting data into the package however it is accessed. The
> Linux-packager preferred practice is to install into the appropriate
> /usr/shared/ subdirec
On Tue, Apr 27, 2010 at 1:24 AM, Toshio Kuratomi wrote:
> On Mon, Apr 26, 2010 at 05:46:55PM -0400, Barry Warsaw wrote:
>> On Apr 26, 2010, at 09:39 PM, Tarek Ziadé wrote:
>>
>> >You should be permissive on that one. Until we know how to describe resource
>> >
global list of variables found in Python.
Then, instead of importing these values (in our plans, the variables
are statically defined), developers will do:
pkgutil.open('MANPATH', 'foo'), where foo.txt is a file under
/somefunkypath in your example
Since you are building
ill need some kind of Pep dictator if there's no consensus. So what
about electing a BPC every year ?
Tarek
--
Tarek Ziadé | http://ziade.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Uns
ts so
I guess it works too.
>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/ziade.tarek%40gmail.com
>
--
Tarek
t; even similar.
>
> Q:
> - Is it a good idea to provide a similar function in
> e.g. shutils module ?
A: Yes :)
Basically, anything useful in distutils.file_util and
distutils.dir_util can maove in Shutil.
That's why I added make_archive (and unpack_archive)
Please add an issue,
s, to propose something.
Regards
Tarek
--
Tarek Ziadé | http://ziade.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%4
On Sun, Jul 4, 2010 at 7:16 PM, Paul Moore wrote:
> On 4 July 2010 17:02, Benjamin Peterson wrote:
>> Now that Python 2.7 is out, I'd like to thank a few of the people who
>> made it possible:
>
> And not forgetting Benjamin himself for managing the whole thing!
+1. Thanks a lot for your hard wo
can work out of the box with
any PyPI server out there.
Tarek
--
Tarek Ziadé | http://ziade.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/p
onent in the tracker.
Let me know if you have/see any problem this revert created.
Regards
Tarek
--
Tarek Ziadé | http://ziade.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
201 - 300 of 475 matches
Mail list logo
