Re: [Python-Dev] PEP 376 - Open questions
2009/7/9 Eric Smith : > P.J. Eby wrote: >>> >>> ISTM that the problem that it solves is uninstall in the absence of >>> the original installer. >> >> Or uninstall where the installer is "setup.py install", actually. > > I think we need to move away from "setup.py install". It's the antithesis of > static metadata. setup.py needs to go away. > > If we have a static metadata file called, say "setup.info", then I'd like to > see: > "bdist_rpm setup.info" produce a .rpm > "bdist_msi setup.info" produce a .msi > "bdist_deb setup.info" produce a .deb > "bdist_egg setup.info" produce a .egg > and so on. > > There might be a library (and I call dibs on the name "distlib" :) that > provides support routines to parse setup.info, but there's no framework > involved. And no need for a plugin system. +1. Now who's going to design & write it? > It's the conflation of "build a package" with "install a package" that > distutils and setuptools has given us (via setup.py) that leads to us never > making progress. Let's just focus on "describe a package" and let the > packagers handle "build a package" and let the installers handle "install > and uninstall a package". Then the packagers (and their associated > installers) can evolve independently of each other. There still needs to be some sort of package build system. I do *not* want to see a situation where users can't easily build their own packages. Not all systems have all Python packages packaged up by "official" system packagers... Paul ___ 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
Re: [Python-Dev] PEP 376 - Open questions
On Thu, Jul 9, 2009 at 12:07 AM, Eric Smith wrote: > Paul Moore wrote: >> >> 2009/7/8 P.J. Eby : >>> >>> If it were being driven by setuptools, I'd have just implemented it >>> myself >>> and presented it as a fait accompli. I can't speak to Tarek's motives, >>> but >>> I assume that, as stated in the PEP, the primary driver is supporting the >>> distutils being able to uninstall things, and secondarily to allow other >>> tools to be built on top of the API. >> >> My understanding is that all of the various distutils PEPs were driven >> by the "packaging summit" ay PyCon. The struggle here seems to be to >> find *anyone* from that summit who will now comment on the discussion >> :-( > > I was there, and I've been commenting! Yes, so Ian Bicking was, and Jim Fulton, and we worked from there on Distutils-SIG. To answer to Paul's question on my motivations for PEP 376, Phillip gave the answers I was going to give. But as Eric says, that was one topic out of others. > > There might have been more discussion after the language summit and the one > open space event I went to. But the focus as I recall was static metadata > and version specification. When I originally brought up static metadata at > the summit, I meant metadata describing the sources in the distribution, so > that we can get rid of setup.py's. From that metadata, I want to be able to > generate .debs, .rpms, .eggs, etc. > > But I think we've veered into metadata that describes what has been > installed. I don't think that's so useful. As I've said, this is private to > the installers. If 2 installers want to communicate with each other about > what they've installed, then they can agree on that data. I just don't find > it generally useful for all installers, and therefore not useful for > distutils. > > I'd like to get back to the metadata that describes the source files. That's > where the real value lies, in my opinion. I'll try and work on a post to > distutils-sig explaining my thinking. Yes please do so, and have a look at Tres and Matthias notes from the summit http://wiki.python.org/moin/Distutils/StaticMetadata but that's another topic, that will deserve a PEP on its own Tarek ___ 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
Re: [Python-Dev] PEP 376 - Open questions
On Thu, Jul 9, 2009 at 3:07 AM, P.J. Eby wrote: > At 09:38 AM 7/9/2009 +0900, Stephen J. Turnbull wrote: >> >> Eric Smith writes: >> >> > But I think we've veered into metadata that describes what has been >> > installed. I don't think that's so useful. As I've said, this is >> private >> > to the installers. If 2 installers want to communicate with each other >> > about what they've installed, then they can agree on that data. I just >> > don't find it generally useful for all installers, and therefore not >> > useful for distutils. >> >> ISTM that the problem that it solves is uninstall in the absence of >> the original installer. > > Or uninstall where the installer is "setup.py install", actually. > Right, and for instance, Fedora packagers are using it to re-package eggs http://fedoraproject.org/wiki/Packaging/Python/Eggs#Providing_Eggs_using_Setuptools with the --root option, so they will get a RECORD file and will be able to set a value for the INSTALLER one, ___ 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
Re: [Python-Dev] PEP 376 - Open questions
On Thu, Jul 9, 2009 at 9:18 AM, Paul Moore wrote: > 2009/7/9 Eric Smith : >> P.J. Eby wrote: ISTM that the problem that it solves is uninstall in the absence of the original installer. >>> >>> Or uninstall where the installer is "setup.py install", actually. >> >> I think we need to move away from "setup.py install". It's the antithesis of >> static metadata. setup.py needs to go away. >> >> If we have a static metadata file called, say "setup.info", then I'd like to >> see: >> "bdist_rpm setup.info" produce a .rpm >> "bdist_msi setup.info" produce a .msi >> "bdist_deb setup.info" produce a .deb >> "bdist_egg setup.info" produce a .egg >> and so on. >> >> There might be a library (and I call dibs on the name "distlib" :) that >> provides support routines to parse setup.info, but there's no framework >> involved. And no need for a plugin system. > > +1. Now who's going to design & write it? Some work has been started on that at the summit too on that, under the "static metadata" name. (see the wiki) Can we move that discussion to distutils-SIG and focus on PEP 376 in this thread ? I am scared to see the discussion going in too many directions, Regards Tarek ___ 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
Re: [Python-Dev] PEP 376 - Open questions
On Thu, Jul 9, 2009 at 3:42 AM, Sridhar Ratnakumar wrote: > Other than easy_install/pip, there is also PyPM which is being developed at > ActiveState. PyPM is the Python package manager much like what ppm is for > ActivePerl. > Great ! besides the RECORD file, anything remark on the PEP from a PyPM point of view ? Once Paul has finished to work on the PEP 302 part of the prototype, maybe we could try it out on PyPM to see how it fits ? > Eventually, I'd like PEP 376 to support system packagers too. So for > example, if you did "apt-get install python-pyqt4", then running "pip > install python-pyqt4" should return without installing anything .. as RECORD > will be part of the .deb previously installed. As for generating the RECORD > file, I vote for generating it during install time (w/ absolute paths). That should be possible for all "python setup.py install"-based systems e.g. stating that if python-pyqt4 is already installed and if the INSTALLER file contains another name than "pip", pip should not try to do anything with it. ___ 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
Re: [Python-Dev] PEP 376 - Open questions
2009/7/9 Tarek Ziadé : > On Thu, Jul 9, 2009 at 3:42 AM, Sridhar > Ratnakumar wrote: >> Other than easy_install/pip, there is also PyPM which is being developed at >> ActiveState. PyPM is the Python package manager much like what ppm is for >> ActivePerl. >> > > Great ! besides the RECORD file, anything remark on the PEP from a > PyPM point of view ? > Once Paul has finished to work on the PEP 302 part of the prototype, > maybe we could try it out > on PyPM to see how it fits ? Note: the "pkgutil2" implementation I pushed to Tarek's bitbucket repository a day or so ago includes PEP 302 support (using a few new finder methods, as proposed). It's ready to go now. It's as compliant with the PEP as possible given the outstanding questions (I've implemented some things on the basis of what I thought was consensus here, even though the PEP has not changed yet to reflect that - using "metadata" rather than "egginfo" in method names, and removing the local= parameter from some of the methods, being the 2 I can recall immediately). I'd like to add a test case using a non-standard PEP 302 importer, but that's a small detail. There are bound to be holes in the implementation, especially around the areas of the open questions that started this thread. I'd appreciate feedback, but I'm not expecting to make code changes until the PEP is changed - it's too much like trying to hit a moving target at the moment! Paul. PS I've added distutils-sig back into the cc list. Please keep "PEP 376" in the subject of any subsequent threads on that list if you want my input, as I don't follow all the traffic on there. ___ 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
Re: [Python-Dev] PEP 376 - Open questions
Eric Smith wrote: > I really don't get this use case of multiple installers trying to > install the same package. There's just no way that running "yum install > twisted" and "apt-get install twisted" and "pip install twisted" are > going to coexist with each other. The best they can do is say "a file > I'm trying to install already exists". Why try for anything else? If that use case doesn't click for you, just focus on the distutils.uninstall use case. At the moment, there is no automatic method for uninstalling a distutils installed package. This PEP is mainly about fixing that situation. However, if we're going to go to all the effort of having an index of distutils-installed packages and the metadata needed to uninstall them, it makes sense to have an official API for querying that datastore. The fact that that API then provides support for "Did someone else install this already?" is really a sideshow. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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
Re: [Python-Dev] "Absolute" paths in PEP 376 RECORD files
P.J. Eby wrote: >> Also, >> why should the RECORD file be generated at all by bdist* commands? > > bdist commands that use "install --root" will get it as a side effect, > so they don't have to do anything special. They needn't even generate > the PREFIXES, if PREFIXES is also generated by "install --root", and > omits the root from the prefixes written. In other words, most bdist > tools wouldn't change. bdist_wininst and bdist_msi might need to > regenerate PREFIXES at actual installation time, but AFAIK those are the > only ones. (And the spec would allow for the possibility that a > PREFIXES file can be incorrect.) I haven't seen any suggestions for handling non-relative paths that are cleaner than this. The distutils based list that Tarek posted also gives a good "starter set" of supported entries in the PREFIXES file: PURELIB= PLATLIB= HEADERS= SCRIPTS= DATA= The question then would be whether relative paths should be handled directly in the RECORD file (as in the current PEP) or by writing a "." into PREFIXES to indicate relative paths. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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
Re: [Python-Dev] PEP 376 - Open questions
On Thu, Jul 9, 2009 at 4:18 PM, Paul Moore wrote:
>>
>> There might be a library (and I call dibs on the name "distlib" :) that
>> provides support routines to parse setup.info, but there's no framework
>> involved. And no need for a plugin system.
>
> +1. Now who's going to design & write it?
I started a new thread on distutils-sig ("setup.py needs to go away")
to avoid jeopardizing this thread. I added the context as well as my
own suggestions for such a design.
David
___
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
Re: [Python-Dev] PEP 376 - Open questions
2009/7/9 Paul Moore : > I'd like to add a test case using a non-standard PEP 302 importer, but > that's a small detail. I've just pushed a PEP 302 importer test case. The level of boilerplate needed is a bit painful, but it's fine as a prototype. When we get consensus on some of the remaining details, I'll tidy up the implementation and streamline the importer requirements at that time. Paul. ___ 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
Re: [Python-Dev] PEP 376 - Open questions
P.J. Eby wrote: At 11:20 PM 7/8/2009 -0400, Eric Smith wrote: P.J. Eby wrote: ISTM that the problem that it solves is uninstall in the absence of the original installer. Or uninstall where the installer is "setup.py install", actually. I think we need to move away from "setup.py install". It's the antithesis of static metadata. Please note that that's entirely out of scope for the PEP at hand. Yes. I'm just trying to point out that the information in the PEP is applicable only to the set of installers that want to work together in some integrated way. It doesn't apply to all installers, and I think that's the bigger problem. But I grant you that the rest of my mail is veering off-topic, and there's a more appropriate thread now on distutils-sig. Eric. ___ 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
Re: [Python-Dev] PEP 376 - Open questions
2009/7/9 Eric Smith : > Yes. I'm just trying to point out that the information in the PEP is > applicable only to the set of installers that want to work together in some > integrated way. It doesn't apply to all installers, and I think that's the > bigger problem. Interoperability standards are only as useful as the number of applications that conform to them. The set of installers that will *not* provide PEP 376 compatible metadata is an important measure of the usefulness of the PEP. Some metadata (the INSTALLER file and the proposed PREFIXES file) must be created by the installer for the PEP 376 APIs to work. Simple cases (relocatable packages with all package data maintained inside the package directory) will work fine even without installer co-operation, as long as the installer copies the whole structure unchanged. But: - some cases are not simple, and it's not clear to me how useful "nearly always accurate" data will be - I understand that some packagers deliberately pick apart Python distributions to conform to OS filesystem layout standards Paul. ___ 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
Re: [Python-Dev] "Absolute" paths in PEP 376 RECORD files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nick Coghlan wrote: > P.J. Eby wrote: >>> Also, >>> why should the RECORD file be generated at all by bdist* commands? >> bdist commands that use "install --root" will get it as a side effect, >> so they don't have to do anything special. They needn't even generate >> the PREFIXES, if PREFIXES is also generated by "install --root", and >> omits the root from the prefixes written. In other words, most bdist >> tools wouldn't change. bdist_wininst and bdist_msi might need to >> regenerate PREFIXES at actual installation time, but AFAIK those are the >> only ones. (And the spec would allow for the possibility that a >> PREFIXES file can be incorrect.) > > I haven't seen any suggestions for handling non-relative paths that are > cleaner than this. The distutils based list that Tarek posted also gives > a good "starter set" of supported entries in the PREFIXES file: > > PURELIB= > PLATLIB= > HEADERS= > SCRIPTS= > DATA= > > The question then would be whether relative paths should be handled > directly in the RECORD file (as in the current PEP) or by writing a "." > into PREFIXES to indicate relative paths. Per discussion with Matthias Klose, it would be useful to split out the following prefixes for "special" kinds of data: - - docs - - i18n / locales Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKVjr6+gerLs4ltQ4RAqwTAKCoohHwkbON3Gg6gmJ4AmZUcPSRdQCgyeZi nBJVZQziPYnWN0cI3B2i4A0= =bSHL -END PGP SIGNATURE- ___ 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
Re: [Python-Dev] "Absolute" paths in PEP 376 RECORD files
At 02:46 PM 7/9/2009 -0400, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nick Coghlan wrote: > P.J. Eby wrote: >>> Also, >>> why should the RECORD file be generated at all by bdist* commands? >> bdist commands that use "install --root" will get it as a side effect, >> so they don't have to do anything special. They needn't even generate >> the PREFIXES, if PREFIXES is also generated by "install --root", and >> omits the root from the prefixes written. In other words, most bdist >> tools wouldn't change. bdist_wininst and bdist_msi might need to >> regenerate PREFIXES at actual installation time, but AFAIK those are the >> only ones. (And the spec would allow for the possibility that a >> PREFIXES file can be incorrect.) > > I haven't seen any suggestions for handling non-relative paths that are > cleaner than this. The distutils based list that Tarek posted also gives > a good "starter set" of supported entries in the PREFIXES file: > > PURELIB= > PLATLIB= > HEADERS= > SCRIPTS= > DATA= > > The question then would be whether relative paths should be handled > directly in the RECORD file (as in the current PEP) or by writing a "." > into PREFIXES to indicate relative paths. Per discussion with Matthias Klose, it would be useful to split out the following prefixes for "special" kinds of data: - - docs - - i18n / locales Unfortunately, the distutils don't currently have a way to specify these. I think we'll need to use only the ones that are distutils install targets at first, but of course the format is extensible. OTOH, one supposed that at least the 'data_files' setup argument could be enhanced to allow a data type flag, that would then be used as a prefix name for those files, with a fallback to the DATA prefix if there isn't one specified. But that's something that will require tagging support in the install_data command. As it is, refactoring the distutils to track prefixes for the RECORD file is probably going to be... challenging. ;-) ___ 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
Re: [Python-Dev] "Absolute" paths in PEP 376 RECORD files
Tres Seaver wrote: > Nick Coghlan wrote: >> The question then would be whether relative paths should be handled >> directly in the RECORD file (as in the current PEP) or by writing a "." >> into PREFIXES to indicate relative paths. > > Per discussion with Matthias Klose, it would be useful to split out the > following prefixes for "special" kinds of data: > > - docs > - i18n / locales There are probably all sorts of other useful distinctions which could be made. However, that would be a topic for a different PEP - as Tarek pointed out, improving distutils is such a huge can of worms that trying to tackle all the issues in a single PEP would most likely just result in developer burnout rather than improvement. The basic PREFIXES discussion is at least somewhat relevant to PEP 376, since the distutils uninstaller needs *some* way for the bdist_* installers to tell it where the non-relative files ended up. Since we need a mechanism for it, it might as well be one that should help with the system package builders needs in the future. Actually adding new categories, while I agree it would be useful, isn't something that is needed to support uninstallation. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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
Re: [Python-Dev] PEP 376 - Open questions
Paul Moore wrote: > - some cases are not simple, and it's not clear to me how useful > "nearly always accurate" data will be Since the accuracy can always be checked against the filesystem, I think the metadata is useful even if not 100% reliable. Applications that need the extra assurance (such as the distutils uninstaller itself) can check the filesytem and complain when it differs from what it is claimed in the package metadata. One thing that did occur to me based on this - do we want the format to support designation of files (such as config files) that *shouldn't* be uninstalled along with everything else? Or are we happy with not mentioning the file in RECORD at all as the means of supporting that use case? Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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
Re: [Python-Dev] "Absolute" paths in PEP 376 RECORD files
At 02:46 PM 7/9/2009 -0400, Tres Seaver wrote: - - docs - - i18n / locales On Jul 9, 2009, at 3:09 PM, P.J. Eby wrote: Unfortunately, the distutils don't currently have a way to specify these. There actually is a way to identify documentation files via setup.cfg, but I don't know if the RPM packagers (or others) use that information. -Fred -- Fred Drake ___ 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
Re: [Python-Dev] "Absolute" paths in PEP 376 RECORD files
On Fri, 10 Jul 2009 05:53:13 +1000, Nick Coghlan wrote: > There are probably all sorts of other useful distinctions which could be > made. However, that would be a topic for a different PEP - as Tarek > pointed out, improving distutils is such a huge can of worms that trying > to tackle all the issues in a single PEP would most likely just result > in developer burnout rather than improvement. All it requires is a few word changes to the documentation to tell programmers to put your documentation in "docs"... If that is going to burn out the existing developers, it might suggest that it is time to get some fresh developers onboard Thats not even a programmatic fix... Regards David ___ 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
Re: [Python-Dev] "Absolute" paths in PEP 376 RECORD files
On Thu, 09 Jul 2009 16:00:41 -0400, Fred Drake wrote: > At 02:46 PM 7/9/2009 -0400, Tres Seaver wrote: >> - - docs >> - - i18n / locales > > > On Jul 9, 2009, at 3:09 PM, P.J. Eby wrote: >> Unfortunately, the distutils don't currently have a way to specify >> these. > > > There actually is a way to identify documentation files via setup.cfg, > but I don't know if the RPM packagers (or others) use that information. Hi, Perphaps the RPM packagers dont use it but the Python Package Manager GUI (http://sourceforge.net/projects/pythonpkgmgr) does. With that, if there is any package documentation in a docs directory the user can click on it and display it. Regards David ___ 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
Re: [Python-Dev] "Absolute" paths in PEP 376 RECORD files
David Lyon wrote: > All it requires is a few word changes to the documentation to tell > programmers to put your documentation in "docs"... There is no current distutils setting to indicate that a particular data file is actually documentation rather than something else - hence such a thing *isn't* just a matter of updating the documentation. If you're actually saying that "hey, that metadata shouldn't be in the code, it should just be a file naming convention" then that *in itself* is a design decision that needs to be discussed and agreed via a PEP (a 'standard' that nobody follows or has even agreed to follow is a useless standard). > If that is going to burn out the existing developers, it might > suggest that it is time to get some fresh developers onboard No, tackling *all* of the distutils issues (supporting uninstallation, moving from setup.py to static metadata for simple cases, providing more fine-grained *programmatic* file categorisation, anything else I've missed) at once would probably burn out anyone that tried to do it. The coding in all this really isn't that hard. It's the gathering of feedback, assessment of use cases and the constant balancing act between retaining enough flexibility to allow for future extensions without a complete rebuild of the design without making the current design so complex as to be unusable. If it was just a matter of throwing some code in the standard library or some words in the documentation and declaring "this is how it shall be from now on" it would have been done years ago :P Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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
[Python-Dev] Search error on tracker?
Before posting http://bugs.python.org/issue6453 I searched the tracker for 'bool TypeError' to avoid making a duplicate report. A few irrelevant hits were return but not the important one http://bugs.python.org/issue6428 which was the one I needed to find. Going back and searching titles for 'TypeError', cut and pasted from the title of my report, I get 6 hits but neither of the two above. Is there some sort of delay in updating the search indexes? Terry Jan Reedy ___ 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
Re: [Python-Dev] Search error on tracker?
Terry Reedy wrote: > Before posting http://bugs.python.org/issue6453 > I searched the tracker for 'bool TypeError' to avoid making a duplicate > report. A few irrelevant hits were return but not the important one > http://bugs.python.org/issue6428 > which was the one I needed to find. When I search for 'bool TypeError', #6428 shows up. Are you sure you had been searching for closed reports as well? > Going back and searching titles for 'TypeError', cut and pasted from the > title of my report, I get 6 hits but neither of the two above. Again, did you search for closed reports also? > Is there some sort of delay in updating the search indexes? No, it's immediate. Regards, 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
