> This is perhaps a naive question, but hat do you gain with the
> intermediate mirror clone of upstream? (Other than filling more of your
> disk?)
In addition to the answer you got: this way of working is also the
process that I arrived at, independently.
I see two uses, both based around the pr
> My question is basically the same as Terry Reedy's, but I'm going to
> phrase it a bit differently:
>
> This is perhaps a naive question, but why do you create a second local
> clone instead of just creating a branch?
IIUC, if you create a named branch, the branch will become globally
visible w
Am 04.07.2010 00:56, schrieb Antoine Pitrou:
> On Sun, 04 Jul 2010 00:51:58 +0200
> "Martin v. Löwis" wrote:
>>>>> I'd love to see a more detailed description of this, including why
>>>>> someone new to Mercurial would choose one over the other.
> Experimenting with the mirror *today* without trying to push changes
> back would give those users a chance to do "familiarization" drills with
> the majority of mercurial's features, with the exception of the final push.
That's true. However, for those users, I'd rather recommend to use hg on
a
> Initially (five years ago!) I tried to overcome these issues by
> improving IDLE, solving problems and adding a few key features.
> Without going into details, suffice to say that IDLE hasn't improved
> much since 2005 despite my efforts. For example, see
> http://bugs.python.org/issue1529142, wh
>> There clearly are *some* folks who care enough about IDLE to submit
>> bug reports and fixes. How about we empower these people by giving at
>> least one of them commit privileges? IDLE development has often been
>> done by people who aren't otherwise contributing to the core, and we
>> surely s
> (This seems to me like an area where a judicious application of PSF
> funds might help; if every single bug were actively triaged and
> responded to, even if it weren't reviewed, and patch contributors were
> directed to take specific steps to elicit a response or a review, the
> fact that patch
> In the 2009 Google Summer of Code I was the mentor for a Brazilian
> student, Guilherme Polo, who completed and extended important
> improvements to IDLE made during the previous year by David Scherer.
> Given the somewhat official nature of this work, I assumed that these
> needed improvements w
> I am aware of the situation with regard to issue reviews, but I think
> with IDLE there is more going on. In other parts of the Python
> codebase, a workaround for a major usability issue wouldn't normally
> have taken nearly three years to resolve after a working patch was
> submitted.
Oh sure
> I think Martin has always supported me in some way and I really
> appreciate that. But, maybe because I won commit privileges solely
> based on GSoC work, I felt other developers wouldn't approve my
> commits without previous discussion and that is the major reason for
> not committing most of my
> My point is that I don't think I am exaggerating IDLE's flaws. I'm not
> saying that it is no longer usable or useful, but I am saying that its
> current state is not "okay".
So can you produce a list of patches that you think can be accepted as-is?
Preferably, make to lists: bug fixes, and new
> FWIW this is why I started IDLE-Spoon (well, continued Noam Raphael's
> project of the same name, in a sense). The idea was to have a fork of
> IDLE with new features which need to be tried out by "beta testers" to
> iron out all of the glitches before making it into the main version,
> like IDLE
> IIRC Terry Reedy has already volunteered to do this
Hmm. I don't recall that happening.
> As for assigning bugs, I've been told to use the maintainer.rst list, so
> either the list is wrong, or I've had finger problems. If it's the
> latter I again say sorry.
I see. What copy have you been u
> What I specifically want right now is Commit Authorization Privilege,
> especially for IDLE,
Not sure who could grant that, but as far as I can: you have it.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mail
Am 12.07.2010 10:06, schrieb Jeroen Ruigrok van der Werven:
> -On [20100712 08:26], Stephen Hansen (apt.shan...@gmail.com) wrote:
>> But I, personally, would consider it a significant loss if IDLE went the way
>> of
>> the dodo or a third-party module.
>
> Why would it be a significant loss if i
Am 12.07.2010 13:01, schrieb Tal Einat:
> On Mon, Jul 12, 2010 at 1:41 AM, "Martin v. Löwis" wrote:
>>> My point is that I don't think I am exaggerating IDLE's flaws. I'm not
>>> saying that it is no longer usable or useful, but I am saying that its
Am 12.07.2010 23:21, schrieb Terry Reedy:
> On 7/12/2010 5:46 AM, Kurt B. Kaiser wrote:
>
>> On Windows, IDLE opens when you right click / edit a .py. Very useful.
>
> On my xp machine with 3.1.2, it edit .py opens with notepad. Perhaps the
> installer just copies forward the association from lon
>> Not normally, no - there's no easy way to connect a checkin message to
>> a committer's email address,
>
> There's a one-to-one mapping somewhere.
Unfortunately, no: we don't have email addresses of all committers.
Regards,
Martin
___
Python-Dev mai
Am 12.07.2010 23:57, schrieb Benjamin Peterson:
> 2010/7/12 "Martin v. Löwis" :
>>>> Not normally, no - there's no easy way to connect a checkin message to
>>>> a committer's email address,
>>>
>>> There's a one-to-one mappin
Am 13.07.2010 00:00, schrieb Terry Reedy:
> On 7/12/2010 5:43 PM, "Martin v. Löwis" wrote:
>> Am 12.07.2010 23:21, schrieb Terry Reedy:
>>> On 7/12/2010 5:46 AM, Kurt B. Kaiser wrote:
>>>
>>>> On Windows, IDLE opens when you right click / edit
Am 13.07.2010 00:48, schrieb Eric Smith:
> On 7/12/2010 6:04 PM, Michael Foord wrote:
>> Given how high traffic python-checkins is I don't consider that a
>> reasonable place to send follow-up and nor do I consider it the
>> responsibility of committers to monitor it. As you said earlier this
>> *i
Maybe going off on a tangent, but I find it frustrating because you
(plural) can't find a given module on the issue tracker. Say I'm looking
for issues relating to smtplib, all I can do is look in the title of the
issue. Have I missed something, or is there a need to have subsections
so that if Li
Thanks for drawing my attention to that; if the people who made OpenID
auth happen are observing this, then thank you all very much!
You're welcome!
Any hope of feeding those changes back upstream so it's available to all
Roundup users at some point?
Hope dies last.
It's main foundation is
No, the reply is fine as far as it goes, and I am sure the poster did
get a reply from c.l.py, but his question revealed a thirst for
knowledge not usually evidenced in non-dev inquiries.
Unfortunately (?) the question also revealed a lack of understanding
of a fairly basic concept. IIUC, he wan
Am 21.07.10 17:47, schrieb Dirkjan Ochtman:
Martin& Tim brought up the issue of externals which the buildbots
use on Windows to bring in and build slightly patched versions of external
libraries such as OpenSSL and sqlite3.
The issue in hgsubversion (which is different from hgsvn) has been
fi
At EuroPython, I sat down with Brett and we propose an approach
how namespace packages get along with import hooks. I reshuffled
the order in which things get done a little bit, and added a
section that elaborates on the hooks.
Basically, a finder will need to support a find_path method,
return a
> Part of me agrees with you regarding the generally different tool
> lifecycle, but another part says we need these tools in the standard
> library or we risk inadvertently breaking the hooks they would still
> rely on, even as third party projects.
>
> I suspect a major factor here relates to th
> Oh, and with business philosophy I mean: mails like the one you start
> this thread with are interpreted by me as being very pushy, overly
> sarcastic and if my project manager at the office sends me an email
> like that I know I have to do it right now. I would dislike to be
> spoken to like thi
>> There's no reason why Tal should be obstructed in his goal of making
>> IDLE at least acceptable again. It's fairly obvious thaat there aren't
>> any committers who have both the inclination /and/ the time to do this,
>> so adding Tal (and other interested parties) as a developer makes a lot
>>
> Interested, yes. But until either a) I can commit patches, or b) there
> is someone who will respond to commit review recommendations with "No,
> here is why not" or "Yes, committed", I will work on other issues, such
> as doc issues, for which I can get responses.
If you are then still interest
Am 26.07.2010 02:24, schrieb Terry Reedy:
> To review a patch on the tracker, I have to read and try to make sense
> of the raw diff file. Sometimes that is easy, sometimes not.
>
> *After* a patch is applied, I can click the rev link and then the
> 'text changed' link and see a nice, colored,
> Sounds like something Ezio could easily do -- adapt Rietveld's upload.py
> to a Roundup extension that submits attachments as patches, adds people
> on nosy to Rietveld CC, &c.
That may not be so easy - you'll have to authenticate to Rietveld from
Roundup.
The other way 'round actually works: i
> Basically, I think what you'd like to have is Martin saying "I'm going to
> work on this feature", in addition to "I implemented this feature now"
> afterwards. That shouldn't be too hard.
I'm not very good at blogging (more specifically, I never blog).
People interested in following even the
> I would classify the changes in three kinds:
>
> - minor: a new feature, a UI bugfix etc
> - important: a new feature that changes a lot the end-user experience
> (like the rating system)
> - major: a change to the APIs (HTTP/XML-RPC)
>
> I think you should briefly present your plans for import
> Should I open a tracker issue to add something to the tracker doc?
I recommend that you use it for some time before changing anything.
I also suggest that, instead of uploading the patch to Rietveld
yourself, you can ask the submitter to do it.
Regards,
Martin
_
Am 27.07.2010 16:56, schrieb Terry Reedy:
> On 7/27/2010 1:42 AM, "Martin v. Löwis" wrote:
>>> Should I open a tracker issue to add something to the tracker doc?
>>
>> I recommend that you use it for some time before changing anything.
>
> How is someon
> On my windows box I have maintainance versions for 2.6, 2.7, 3.1 and 3.2
> plus tortoisesvn. Download the patch file, right click, select
> tortoisesvn then apply patch. Go to the version I'm interested in.
> Double click to select the unit test file to start things off. If I'm
> lucky get a col
> Sure it could make a difference. People who submit issues will
> appreciate *some* response a great deal more than no response.
That depends. Sometimes, people post to the bug tracker to get help,
and they will get sad/driven away/angry when they get no response;
sometimes, if they get a respons
> I just wanted to point this out. We‘ll attempt some local workarounds
> here, but it should otherwise be simple to modify pickling to optionally
> turn off this optimization and always generate the same output
> irrespective of the internal reference counts of the objects.
I think there are man
> I don't really have any answer to this problem right now. Is it
> possible to set up a local buildslave-like environment (so I can run
> the test suite on my development PC without needing to set up access
> and register that PC as a temporary buildslave, which wouldn't be
> practical for me)? If
> http://docs.pythonsprints.com/core_development/beginners.html
>
> Building ssl requires Perl and nasm, and gets completed as a post-build
> step. I haven't done that in a while but it's documented in
> PCBuild/readme.txt. That's the stuff I'll be adding to the above document.
Perl shouldn't be
>>> It happens when running test_smtplib before test_smtpb:
>>
>> Nice! How did you work that out? I'd like to learn how to diagnose
>> this sort of thing, because it seems to come up a lot, and I'm not
>> much use at the moment :-)
>
> I simply tried to run test_smtplib before test_smtpd.
A more
> This whole discussion seems to make it clear that the release manager
> procedures are still ill-defined in certain areas.
No. It rather makes clear that people who never had the role of release
manager
> Otherwise a release
> manager could proceed by reading a web page an even, heaven help us,
Am 04.08.2010 21:03, schrieb Paul Moore:
> On 4 August 2010 18:42, "Martin v. Löwis" wrote:
>>> I don't really have any answer to this problem right now. Is it
>>> possible to set up a local buildslave-like environment (so I can run
>>> the test suit
>> If you mean to imply that a release manager should care for the stability
>> of "their" branch also in between of releases -- I'd love to do that,
>> but I'd need a 36-hour day then.
>>
> I'll see if I can get God to extend it for you. I honestly do understand
> that everyone else works under th
Am 08.08.2010 02:12, schrieb Nick Coghlan:
> On Sun, Aug 8, 2010 at 5:55 AM, wrote:
>> I know the question is why anybody should want to do so, but I do
>> think that a project which depends on a non-free compiler is not free
>> after all.
>
> It's a philosophical question
It's also a technical
Am 08.08.2010 03:27, schrieb Greg Ewing:
> Nick Coghlan wrote:
>
>> This used to be more of an issue because MS didn't provide a decent
>> free compiler for their platform. These days (since the release of
>> Visual Studio Express), we expect that people willing to use (or
>> support) a closed OS
Am 08.08.2010 22:03, schrieb Terry Reedy:
> The usual Friday Summary of Python Trackers Issues did not appear on
> Gmane. Was one generated?
Sending it failed due to a hard disk problem.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
> Python's distutils do not work with the SDK compiler, only Visual Studio.
That is not true.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailm
Am 09.08.2010 23:00, schrieb Steve Holden:
> On 8/9/2010 2:47 PM, Sturla Molden wrote:
>>> Terry Reedy:
> [...]
>>
>> Python's distutils do not work with the SDK compiler, only Visual Studio.
>> Building Python extensions with the SDK compiler is not as easy as it
>> could (or should) be.
>>
> At o
>> Please understand that this very choice is there already.
>>
> That's great. Is that what the documentation refers to when it says
Correct.
> That isn't particularly clear to me, but it may be to others more
> familiar with building on Windows.
People familiar with that documentation fragment
Am 10.08.2010 04:47, schrieb Nick Coghlan:
> On Tue, Aug 10, 2010 at 2:10 AM, alexander.belopolsky
> wrote:
>> +PS: In the standard Python distribution, this file is encoded in UTF-8
>> +and the list is in rough alphabetical order by last names.
>>
>> David Abrahams
>> Jim Ahlstrom
>> @@ -28,6 +
Am 10.08.2010 05:49, schrieb Alexander Belopolsky:
> On Mon, Aug 9, 2010 at 11:32 PM, Nick Coghlan wrote:
>> On Tue, Aug 10, 2010 at 1:24 PM, Alexander Belopolsky
>> wrote:
>>> Was it on IRC? I do remember discussion, but forgot the answer. :(
>>
>> python-dev or python-checkins I think, but I do
> I am not 100% happy with this because I am sure people will keep
> discovering that the order in the file does not match the order
> suggested by their favorite sort program. I was also hoping to learn
> from this discussion what the state of the art in in sorting unicode
> words is. I believe
> If I were committing a patch and was checking to see whether a name that
> started with a decorated A (or any other letter) were already in the
> list, I would look in the appropriate place in the A (or other) section,
> not after Z.
>
> Everyone working on the English-based Python distribution
Am 11.08.2010 00:35, schrieb Alexander Belopolsky:
> On Tue, Aug 10, 2010 at 6:29 PM, "Martin v. Löwis" wrote:
> ..
>> So where do you put Γεώργιος Μπουτσιούκης?
>>
>
> or Александр Белопольский for that matter? :-)
If you care about that, feel free to add t
> My argument goes that one of the biggest differences between the
> GNU/Linux and the Windows way of computing is the barrier between user
> and programmer. In the Windows way, you are either a user or a
> programmer.
Such arguments are off-topic for python-dev; please use one of the
Linux advoc
> The question is "who will support those folks?" I don't see any
> reason why you or Martin should support MSYS/mingw if you don't want
> to, but please don't put down the folks who ask for it. Just say "no,
> it's not worth it". Or maybe, "if you want to do the work, I might
> contribute some
Am 13.08.2010 20:45, schrieb Sturla Molden:
>
>> The problem really is that when people ask for MingW support, they mean
>> all kinds of things,
>
> Usually it means they want to build C or C++ extensions, don't have Visual
> Studio, don't know about the SDK compiler, and have misunderstood the C
> I'm starting a project that aims at first to internationalize the python
> interpreter, so it could be localized. I want to know if this could be
> considered for the main trunk of python.
It's not exactly clear what you are proposing, but most likely, the
answer is "no". If you plan to interna
Am 14.08.2010 08:35, schrieb Zooko O'Whielacronx:
> On Sat, Aug 7, 2010 at 2:14 PM, Steve Holden wrote:
>> There have certainly been demonstrations that Python can be compiled
>> with mingw, but as far as I am aware what's missing is a developer
>> sufficiently motivated to integrate that build s
I have set up 4-CPU system as a build slave, and enabled parallel builds
on it; this means that the Makefile and the testsuite is run in
parallel. configure and setup.py remain sequential. You can watch its
waterfall at
http://tinyurl.com/39a8u8m
Notice that the 2.6 branch doesn't support the -j
Am 18.08.2010 17:11, schrieb Michael Foord:
> Could (and should) the online Python 3.1 docs be updated to show Python
> 2.7 as stable?
I think the answer is "no, it could not".
How many old documentation sets would you want to go through, and
regenerate them? There is also
http://docs.python.org
> (I have another request for the dev FAQ - could we get an FAQ entry
> about how to update the FAQ itself? I usually just post here in the
> hopes that someone will fix it, but we should be able to do better
> than that. People have told me many times in the past how it actually
> gets updated, bu
> I do it every time myself, AFAIK it reduces the workload of people
> that are making sure all pending patches were applied.
Do we really have any such people still?
I thought they have all given up long ago.
Regards,
Martin
___
Python-Dev mailing lis
> May I have commit privileges so that I can commit these patches and
> future patches in a similar state?
Please send me your SSH key.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
> OTOH, I suspect there won't be *that* many documentation fixes for Python 2.6
> and that the overhead will be minimal. What did we do for Python 2.5?
The question really is whether there is any chance that they will get
released, in some form. There won't be further binary releases (at least
no
Am 25.08.2010 17:03, schrieb Adal Chiriliuc:
>> The question really is whether there is any chance that they will get
>> released, in some form. There won't be further binary releases (at least
>> not from python.org), so there definitely won't be a CHM release.
>
> Speaking about the CHM, why doe
> I like how the django project present their documentation: there is
> a little informational text at the head of each doc, saying that
> "you're not browsing the most up-to-date documentation, you can
> find the last one here"; maybe can we do a similar thing for the python
> doc ?
In principle,
>That is pretty good mojibake. One of the problems of providing
> localized error messages is that the messages may be messed up at
> different stages. The original text was
> A létező kapcsolatot a távoli állomás kényszerítetten bezárta.
>It was printed in iso8859_2 (ISO standard for Easte
Am 26.08.2010 08:18, schrieb Terry Reedy:
> On 8/25/2010 9:06 PM, Neil Hodgson wrote:
>> Terry Reedy:
>>
>>> File "C:\Python26\lib\socket.py", line 406, in readline
>>> data = self._sock.recv(self._rbufsize)
>>> socket.error: [Errno 10054] A lÚtez§ kapcsolatot a tßvoli ßllomßs
>>> kÚnyszerÝte
Am 26.08.2010 01:28, schrieb Adal Chiriliuc:
> And there doesn't seem to be a link to
> download the CHM files (the last I could find on python.org is for
> Python 2.6.2).
Thanks for pointing that out; there is now.
Regards,
Martin
___
Python-Dev mailin
> Regards, and a toast to 2.6.6!
Prost!
Martin
___
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
I have now started an initial patch for PEP 384, in the pep-0384 branch.
This has the following features:
- modules can be compiled under Py_LIMITED_API
- Tools/scripts/abitype.py converts C code containing static
PyTypeObject definitions to use the new API for type definitions.
The following as
>> This leads me to a question: how do these configure options affect the
>> PEP 384 stable ABI? That PEP is currently silent on the issue, while
>> PEP 3149 appears to implicitly assume that "abi3" completely specifies
>> the ABI.
>
> It's a great question - perhaps Martin can chime in? It may b
> This is from tp_new and tp_dealloc, right? I think we should probably
> provide assessors PyObject_Alloc and PyObject_FreeObject.
Correct, and yes, that sounds like a good approach.
>> - PyObject_Print is used, but can't be supported, as it uses a FILE*
>> parameter
>
> I thought tp_print was
> It would be interesting to know how, in practice, these FILE pointers
> come to life. In my experience they are generally obtained via fopen.
I think that experience can't be generalized. I personally guess that
in most cases, the FILE* being passed across CRT boundaries is stdout.
> If that i
> This sounds like the issues such a mix can cause are mostly
> theoretical and don't really bother much in practice, so
> PEP 384 on Windows does have a chance :-)
Actually, the CRT issues (FILE* in particular) have been
causing real crashes for many years, for many people.
Regards,
Martin
> What I think would be a mistake would be to define the API in terms of
> Windows-specific quirks. All this discussion seems bent on satisfying
> the needs of Windows developers at the expense of non-Windows
> developers. "FILE*" is a perfectly standard C feature (and a
> widely-used one at that).
> Please consider this: even without relying on PEP 384, using FILE*
> is /already/ dangerous; because you might compile an extension with a
> different compiler version than Python was compiled with.
It's only dangerous *if* you compile with a different compiler.
That's why we take serious precau
> -1 on always using wchar_t as well. Python's default is UCS2 and the
> stable ABI should not change that.
It's not really Python's default. It is what configure.in does by
default. Python's default, on Linux, is UCS-4.
> I also think that this information is not relevant for the stable
> ABI: E
I know the PEP is accepted, but I would still like to see some
changes/clarifications.
1. What is the effect of this PEP on Windows? Is this a Linux-only
feature? If not, who is going to provide the changes for Windows?
(More specifically: if this is indeed meant for Windows, and
if no Wi
>> 1. What is the effect of this PEP on Windows? Is this a Linux-only
>>feature? If not, who is going to provide the changes for Windows?
>>(More specifically: if this is indeed meant for Windows, and
>>if no Windows implementation arrives before 3.2b1, I'd ask that
>>the changes be
Am 07.09.2010 19:46, schrieb M.-A. Lemburg:
> "Martin v. Löwis" wrote:
>>> -1 on always using wchar_t as well. Python's default is UCS2 and the
>>> stable ABI should not change that.
>>
>> It's not really Python's default. It is what confi
> I only mandated ./configure-based builds to be PEP 3149 conforming. I have no
> objection to expanding the PEP to include Windows builds, but I'm not sure
> it's necessary and it would take a Windows build expert to make and test those
> changes.
>
> Does PEP 3149 have any advantage for Windows
Am 07.09.2010 19:48, schrieb M.-A. Lemburg:
> "Martin v. Löwis" wrote:
>>
>>> This sounds like the issues such a mix can cause are mostly
>>> theoretical and don't really bother much in practice, so
>>> PEP 384 on Windows does have a chance :-)
> If it's useful on unix like systems, why shouldn't it be useful on
> windows? Multiple versions of python can be installed on windows
> too. And people might also like to share their packages between
> installations.
Multiple versions of Python install into distinct directories, so
extension mod
> On http://bugs.python.org/issue9778 you elaborated on what the PEP would
> entail in its current state:
>
> “No, vice versa. The PEP promises that the ABI won't change until
> Python 4. For any change that might break the ABI, either a
> backwards-compatible solution needs to be found, or the ch
> That said, looking at the PEP, I was wondering whether fields such as
> ob_type, ob_refcnt, ob_size have to be directly accessible, rather than
> through a macro-turned-into-a-function such as Py_REFCNT().
That they are macros still is primarily for performance reasons. For
ob_type, that may be
Am 13.09.2010 17:36, schrieb Antoine Pitrou:
>
>>> I meant how these decisions are implemented. Is there a configure
>>> switch (there doesn't seem to be)? Does it require patching Python?
>>
>> Ah, no. Standard configure switches are used. Debian (inherited by Ubuntu)
>> has a post-installation
Hi Sebastien,
Unfortunately, I don't think this solution is possible for me: I don't
think the security team in my company would appreciate that a server
inside our network runs some arbitrary shell commands provided by some
external source.
I still think this would be the best thing, and I fe
Am 16.09.10 02:02, schrieb John Nagle:
On 9/15/2010 4:44 PM, python-dev-requ...@python.org wrote:
``SERVER_PORT`` must be a bytes instance (not an integer).
What's that supposed to mean? What goes in the "bytes
instance"? A character string in some format? A long binary
number? If the latter,
I am in full agreement with Tarek here. At ActiveState, we maintain
our own index that differs from PyPI in two ways (among others):
I think you are saying something very different from what Tarek
says. IIUC, you are saying that egg-info is ill-defined and may
cause subtle problems. So you are s
With the distutils2 work very close to landing in the standard library,
providing infrastructure that will cause tools to *depend* on the old
formats is a very bad idea.
I think you are misunderstanding. The infrastructure will *not* depend
on the old formats. Instead, packaging that have that i
I think you are misunderstanding. The infrastructure will *not* depend
on the old formats. Instead, packaging that have that information will
provide it, packages that don't will not. The infrastructure is entirely
agnostic on whether the data is available or not. In particular, it will
not try to
No. See above comment. If exposing this information has no value then
don't do it. If it does have value, then we are blessing it - and
therefore blessing it *over* other formats.
No: not *over*. Only over formats that don't get exposed. However,
the PEP 345 data are *already* exposed, via HTML,
So if the use case is to provide dependency information exposing
egg_info is not the right way to do it - and tools that use it will be
using potentially (and frequently) inaccurate information. I stand by
the point that once we start providing this information tools will start
using it, and they
So, I don't understand what is the benefit here, since a serious
installer will re-run egg_info every time.
I think the main applications that people are after are not builds.
They want the dependency information without downloading the packages,
and dependency information for packages they have
So you are fine with publishing "slightly incorrect" metadata at PyPI
? I am not.
I really have no intuition for in how many cases the data will be
incorrect. However, if users find that the data is incorrect for
specific package, they ought to complain to the maintainer.
I don't understand
Am 18.09.10 17:49, schrieb P.J. Eby:
At 05:19 PM 9/18/2010 +0200, Martin v. Löwis wrote:
In the specific case of tl.eggdeps, the dependency information is only
used to create printable graphs. If this turns out to be slightly
incorrect, people would notice if they try to use the packages in
1201 - 1300 of 5277 matches
Mail list logo
