Re: [Python-Dev] Define metatype and a type that uses it
Amaury,
Thank you very much for your detailed explanation. It helps to
understand it better, and it mostly works now. There is one thing
however:
On Wed, Jul 8, 2009 at 17:35, Amaury Forgeot d'Arc wrote:
> - Don't define a JObjectMeta struct, use JObjectType directly instead.
> An instance of the metatype is the type itself!
> - Don't set JObjectMetaType.tp_basicsize, let it inherit from the base
> type (the correct value would be sizeof(PyHeapTypeObject), this is
> important in order to create derived classes in python)
I'd like to add a C pointer field to the metatype instance (the type).
So, contrary to your advice, I have defined:
typedef struct {
PyHeapTypeObject x;
void* p;
} JObjectMeta;
This seems the way to do it for objects, but for types, it doesn't
seem right, as the p member turns out to be overwritten unexpectedly
at runtime.
Reading Python's object.h file it turns out that PyHeapTypeObject
'extends' PyTypeObject, which in turn has a PyObject_VAR_HEAD init
macro. So mustn't:
PyTypeObject JObjectMetaType = {
PyObject_HEAD_INIT(NULL)
};
actually be:
PyTypeObject JObjectMetaType = {
PyVarObject_HEAD_INIT(NULL, 1)
};
with:
JObjectMetaType.tp_basic_size = sizeof(JObjectMeta);
JObjectMetaType.tp_itemsize = sizeof(void*);
I tried this, but it doesn't keep my app from dumping core on an
overwritten 'p'.
My question basically is: how can I define a pointer for each type
created with this metatype, such as is intended by the JObjectMeta
struct?
Best regards
Erik Groeneveld
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Define metatype and a type that uses it
Hi,
2009/7/13 Erik Groeneveld :
> Amaury,
>
> Thank you very much for your detailed explanation. It helps to
> understand it better, and it mostly works now. There is one thing
> however:
>
> On Wed, Jul 8, 2009 at 17:35, Amaury Forgeot d'Arc wrote:
>> - Don't define a JObjectMeta struct, use JObjectType directly instead.
>> An instance of the metatype is the type itself!
>> - Don't set JObjectMetaType.tp_basicsize, let it inherit from the base
>> type (the correct value would be sizeof(PyHeapTypeObject), this is
>> important in order to create derived classes in python)
>
> I'd like to add a C pointer field to the metatype instance (the type).
> So, contrary to your advice, I have defined:
>
> typedef struct {
> PyHeapTypeObject x;
> void* p;
> } JObjectMeta;
>
> This seems the way to do it for objects, but for types, it doesn't
> seem right, as the p member turns out to be overwritten unexpectedly
> at runtime.
>
> Reading Python's object.h file it turns out that PyHeapTypeObject
> 'extends' PyTypeObject, which in turn has a PyObject_VAR_HEAD init
> macro. So mustn't:
>
> PyTypeObject JObjectMetaType = {
> PyObject_HEAD_INIT(NULL)
> };
>
> actually be:
>
> PyTypeObject JObjectMetaType = {
> PyVarObject_HEAD_INIT(NULL, 1)
> };
>
> with:
>
> JObjectMetaType.tp_basic_size = sizeof(JObjectMeta);
> JObjectMetaType.tp_itemsize = sizeof(void*);
>
> I tried this, but it doesn't keep my app from dumping core on an
> overwritten 'p'.
>
> My question basically is: how can I define a pointer for each type
> created with this metatype, such as is intended by the JObjectMeta
> struct?
The best is probably to store it in the class dictionary:
PyObject_SetAttrString(self, "_javatype_", PyLong_FromVoidPtr(p));
--
Amaury Forgeot d'Arc
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.6.3 unittest change breaks nose (issue 6418)
jason pellerin wrote: Bringing python-dev into the discussion at Barry's request. The summary is that a recent change to unittest.TestProgram breaks nose by moving self.testRunner initialization from it's old home in TestProgram.runTests to TestProgram.__init__. The very small patch attached to the ticket moves it back to runTests. Here's the ticket: http://bugs.python.org/issue6418 And a link to the testing in python list discussion: http://lists.idyll.org/pipermail/testing-in-python/2009-July/002032.html I can look at this - no reason for it not to be included in 2.6.3 and ported to trunk. Sorry for the late reply - I've been on holiday. Michael JP (primary author of nose) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Windows Toolchain
Hello, I am trying to build Python 3.1 on Windows XP Pro (32 bit) using Microsoft Visual C++ Express Edition in order to test some modifications I made to the _subprocess.c file as part of my Google Summer of Code proposal. I cannot seem to figure out how to compile Python on Windows and could use some guidance. The Visual Studio Solution file ../PCbuild/pcbuild.sln does not work when I attempt to open and no error message is given when clicked. When opened from the Visual C++, it says "Solution folders are not supported in this version of the application." Any advice is greatly appreciated, Eric ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows Toolchain
Sorry, forgot to include my build log: Command Lines: http://pastebin.com/f25614b01 Output Window: > Compiling... > python.c > Compiling resources... > Microsoft (R) Windows (R) Resource Compiler Version 6.1.6723.1 > Copyright (C) Microsoft Corporation. All rights reserved. > Linking... > LINK : fatal error LNK1181: cannot open input file '.\python31_d.lib' > Creating browse information file... > Microsoft Browse Information Maintenance Utility Version 9.00.30729 > Copyright (C) Microsoft Corporation. All rights reserved. On Mon, Jul 13, 2009 at 10:46, Eric Pruitt wrote: > Hello, > > I am trying to build Python 3.1 on Windows XP Pro (32 bit) using Microsoft > Visual C++ Express Edition in order to test some modifications I made to the > _subprocess.c file as part of my Google Summer of Code proposal. I cannot > seem to figure out how to compile Python on Windows and could use some > guidance. The Visual Studio Solution file ../PCbuild/pcbuild.sln does not > work when I attempt to open and no error message is given when clicked. When > opened from the Visual C++, it says "Solution folders are not supported in > this version of the application." > > Any advice is greatly appreciated, > Eric > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows Toolchain
I opened the solution, hit Ctrl+F5 and it began compiling but it fails with this error: LINK :fatal error LNK1181: cannot open input file '.\python31_d.lib' How do I specify that "pythoncore" be built? When I follow your instructions, right clicking on the "python" project in the "Solution Explorer" panel, I get the exact same link error as above. If I hit F7, the build log changes completely. The last lines of output with F7 are as follows: > 21>Build log was saved at "file://C:\Documents and Settings\James\Desktop\Python-3.1\PCbuild\Win32-temp-Debug\select\BuildLog.htm" > 21>select - 1 error(s), 0 warning(s) > == Build: 0 succeeded, 20 failed, 4 up-to-date, 1 skipped == On Mon, Jul 13, 2009 at 11:03, Amaury Forgeot d'Arc wrote: > Hi, > > 2009/7/13 Eric Pruitt : > > Hello, > > > > I am trying to build Python 3.1 on Windows XP Pro (32 bit) using > Microsoft > > Visual C++ Express Edition in order to test some modifications I made to > the > > _subprocess.c file as part of my Google Summer of Code proposal. I cannot > > seem to figure out how to compile Python on Windows and could use some > > guidance. The Visual Studio Solution file ../PCbuild/pcbuild.sln does not > > work when I attempt to open and no error message is given when clicked. > > Is Visual C++ correctly installed? > > > When > > opened from the Visual C++, it says "Solution folders are not supported > in > > this version of the application." > > This is a warning from the Express Edition, which has absolutely no > impact on the build. You can safely ignore it and continue. > > What steps did you perform exactly? From your build log the > "pythoncore" project was not built. Why? > > The following has always worked for me: In the "Solution explorer" > panel, right-click on the "python" project, and click "Build". This > should build the project and all its dependencies. > Or just hit the F7 key and watch the whole solution build. > > -- > Amaury Forgeot d'Arc > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.6.3 unittest change breaks nose (issue 6418)
jason pellerin wrote: Bringing python-dev into the discussion at Barry's request. The summary is that a recent change to unittest.TestProgram breaks nose by moving self.testRunner initialization from it's old home in TestProgram.runTests to TestProgram.__init__. The very small patch attached to the ticket moves it back to runTests. Here's the ticket: http://bugs.python.org/issue6418 And a link to the testing in python list discussion: http://lists.idyll.org/pipermail/testing-in-python/2009-July/002032.html This is fixed on the Python 2.6 maintenance branch (revision 73997) but needs fixing on trunk. No problem applying the fix but I'm struggling to test this without causing spurious extra output on stderr. The style of dependency injection used means that merely overriding sys.stderr does nothing and a custom stream can't be used as we want to test the default initialisation behavior. Michael Foord JP (primary author of nose) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows Toolchain
It is indeed the file ../PCBuild/pcbuild.sln. The line endings appear to be Unix style but after fixing them, I still have the same problem. On Mon, Jul 13, 2009 at 11:43, Amaury Forgeot d'Arc wrote: > 2009/7/13 Eric Pruitt : > > I opened the solution, hit Ctrl+F5 and it began compiling but it fails > with > > this error: > > LINK :fatal error LNK1181: cannot open input file '.\python31_d.lib' > > > > How do I specify that "pythoncore" be built? When I follow your > > instructions, right clicking on the "python" project in the "Solution > > Explorer" panel, I get the exact same link error as above. If I hit F7, > the > > build log changes completely. The last lines of output with F7 are as > > follows: > > > >> 21>Build log was saved at "file://C:\Documents and > >> > Settings\James\Desktop\Python-3.1\PCbuild\Win32-temp-Debug\select\BuildLog.htm" > >> 21>select - 1 error(s), 0 warning(s) > >> == Build: 0 succeeded, 20 failed, 4 up-to-date, 1 skipped > >> == > > > > Did you open the sub-project "python.vcproj" by mistake? > You must open the solution file: "pcbuild.sln". > > And if pcbuild.sln does not load correctly, check that it has correct > line endings: it is supposed to have DOS line endings. > > -- > Amaury Forgeot d'Arc > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows Toolchain
On Mon, Jul 13, 2009 at 11:46, Eric Pruitt wrote: > Hello, > > I am trying to build Python 3.1 on Windows XP Pro (32 bit) using Microsoft > Visual C++ Express Edition in order to test some modifications I made to the > _subprocess.c file as part of my Google Summer of Code proposal. I cannot > seem to figure out how to compile Python on Windows and could use some > guidance. The Visual Studio Solution file ../PCbuild/pcbuild.sln does not > work when I attempt to open and no error message is given when clicked. When > opened from the Visual C++, it says "Solution folders are not supported in > this version of the application." What version of Visual C++ Express are you using? This sounds suspiciously like a version issue. -- Tim Lesher ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows Toolchain
2009/7/13 Eric Pruitt : > It is indeed the file ../PCBuild/pcbuild.sln. The line endings appear to be > Unix style but after fixing them, I still have the same problem. Where did you get your copy of the Python source from? If it's from Subversion, I'm surprised the line endings are wrong. If it's Mercurial, then this may be indicative of the still somewhat open question of how line endings will be handled in Mercurial (which doesn't have a server-side way of saying that a file should use platform-native line endings). If you still have the same problem after fixing the file, this may indicate further damage, or maybe the fix isn't doing the right thing as the file has already been opened (and mangled) by Visual Studio, I'd suggest trying to reproduce your issue with a clean checkout from Subversion. It would also help if you could describe precisely the steps you took to download the sources and build them (I appreciate that this may not be easy now, after you've tried various things). Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows Toolchain
The code I downloaded was the official Python 3.1 release tarball. I only checked the line endings in the pcbuild.sln file so I am not sure about the other files. I will attempt to build the Python 3000 SVN trunk shortly and report back. On Mon, Jul 13, 2009 at 13:09, Paul Moore wrote: > 2009/7/13 Eric Pruitt : > > It is indeed the file ../PCBuild/pcbuild.sln. The line endings appear to > be > > Unix style but after fixing them, I still have the same problem. > > Where did you get your copy of the Python source from? If it's from > Subversion, I'm surprised the line endings are wrong. If it's > Mercurial, then this may be indicative of the still somewhat open > question of how line endings will be handled in Mercurial (which > doesn't have a server-side way of saying that a file should use > platform-native line endings). > > If you still have the same problem after fixing the file, this may > indicate further damage, or maybe the fix isn't doing the right thing > as the file has already been opened (and mangled) by Visual Studio, > > I'd suggest trying to reproduce your issue with a clean checkout from > Subversion. > > It would also help if you could describe precisely the steps you took > to download the sources and build them (I appreciate that this may not > be easy now, after you've tried various things). > > Paul. > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows Toolchain
2009/7/13 Paul Moore : > 2009/7/13 Eric Pruitt : >> It is indeed the file ../PCBuild/pcbuild.sln. The line endings appear to be >> Unix style but after fixing them, I still have the same problem. [...] > I'd suggest trying to reproduce your issue with a clean checkout from > Subversion. FWIW, I did: svn co http://svn.python.org/projects/python/tags/r31/ py31 Open pcbuild in Visual C++ 2008 Express. OK on the warning about solution folders. Right click "python" and choose "Build". Works OK here. Also works if I download Python-3.1.tgz from python.org and unpack it using (command line) bsdtar. I wonder - did you use WinZip to unpack the archive? That has some sort of brain-damaged "Smart" CRLF conversion for tar files, which may have screwed up your files. Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows Toolchain
Well, I narrowed the culprit down to Windows DEP. I had been having trouble with it for some time now, with it raising an error for nearly every program I ran so I just disabled it completely and Python now compiles fine. Thank you all for the assistance. On Mon, Jul 13, 2009 at 13:42, Paul Moore wrote: > 2009/7/13 Paul Moore : > > 2009/7/13 Eric Pruitt : > >> It is indeed the file ../PCBuild/pcbuild.sln. The line endings appear to > be > >> Unix style but after fixing them, I still have the same problem. > [...] > > I'd suggest trying to reproduce your issue with a clean checkout from > > Subversion. > > FWIW, I did: > > svn co http://svn.python.org/projects/python/tags/r31/ py31 > > Open pcbuild in Visual C++ 2008 Express. OK on the warning about > solution folders. > > Right click "python" and choose "Build". > > Works OK here. Also works if I download Python-3.1.tgz from python.org > and unpack it using (command line) bsdtar. I wonder - did you use > WinZip to unpack the archive? That has some sort of brain-damaged > "Smart" CRLF conversion for tar files, which may have screwed up your > files. > > Paul. > ___ Python-Dev mailing list [email protected] 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 Fri, 10 Jul 2009 01:56:36 -0700, Paul Moore wrote: 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? No. In my view, the uninstall feature is a relatively minor issue - people who want uninstall facilities generally use system packages (or complain that easy_install doesn't support uninstallation :-)). They aren't using setup.py install. (Of course, my experience is minimal in this regard, so maybe I'm wrong). Remember that the PEP says "Distutils will provide a **very basic** uninstall function" (my emphasis). Unless I'm misunderstanding, no-one is intending to use the new distutils uninstall feature in their own package manager (bdist_wininst, RPM, apt, ...) Perhaps distutils can also provide an `uninstall` hook that application can use to do some pre-processing? import distutils.installer distutils.installer.register_uninstall_hoook(my_uninstall_hook) I imagine that packages like pywin32 may have to register DLLs (install time) and unregister them (uninstall time). Just a wild idea .. I understand that this may not be related to the current PEP. :-) -srid ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows Toolchain
Paul Moore wrote: > 2009/7/13 Eric Pruitt : >> It is indeed the file ../PCBuild/pcbuild.sln. The line endings appear to be >> Unix style but after fixing them, I still have the same problem. > > Where did you get your copy of the Python source from? If it's from > Subversion, I'm surprised the line endings are wrong. If it's > Mercurial, then this may be indicative of the still somewhat open > question of how line endings will be handled in Mercurial (which > doesn't have a server-side way of saying that a file should use > platform-native line endings). For the record, we only have SVN set to force Windows line endings for the old VC6 project files (.dsp and .dsw). The newer versions of Visual Studio can handle Unix line endings just fine so the .sln/.vcprops/etc files are left with native line endings and hence end up with Unix line endings in the source tarball. Cheers, Nick. P.S. I must admit I've never really understood how Data Execution Prevention is ever going to work in a world with interpreted languages and just in time compilers... the line between data and code is fuzzier than one might think for a lot of programs... -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows Toolchain
Nick Coghlan wrote: > For the record, we only have SVN set to force Windows line endings for > the old VC6 project files (.dsp and .dsw). The newer versions of Visual > Studio can handle Unix line endings just fine so the .sln/.vcprops/etc > files are left with native line endings and hence end up with Unix line > endings in the source tarball. It would appear that Amaury just changed that. I'm not sure that was actually necessary though (since nobody else has complained and the original poster of this thread discovered the line endings weren't the problem after all). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows Toolchain
> I am trying to build Python 3.1 on Windows XP Pro (32 bit) using > Microsoft Visual C++ Express Edition in order to test some modifications > I made to the _subprocess.c file as part of my Google Summer of Code > proposal. As a posting guideline, please be careful to not post too many messages in quick succession. If you run into a problem, try to solve it for yourself. If you fail, consult your mentor and/or wait a couple of hours. Then, when posting, summarize your findings and the alternatives that you tried unsuccessfully. If people learn that you post while being in the process of working on a problem, they will learn that it is better to wait a day or two before responding, in case you figure it out on your own. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows Toolchain
2009/7/13 Nick Coghlan : > Nick Coghlan wrote: >> For the record, we only have SVN set to force Windows line endings for >> the old VC6 project files (.dsp and .dsw). The newer versions of Visual >> Studio can handle Unix line endings just fine so the .sln/.vcprops/etc >> files are left with native line endings and hence end up with Unix line >> endings in the source tarball. > > It would appear that Amaury just changed that. I'm not sure that was > actually necessary though (since nobody else has complained and the > original poster of this thread discovered the line endings weren't the > problem after all). Well, I was caught several times by this line ending problem. And the first time, I did not even understand what was going on... -- Amaury Forgeot d'Arc ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows Toolchain
On Mon, Jul 13, 2009 at 2:04 PM, Nick Coghlan wrote: > > P.S. I must admit I've never really understood how Data Execution > Prevention is ever going to work in a world with interpreted languages > and just in time compilers... the line between data and code is fuzzier > than one might think for a lot of programs... The OS has to provide a mechanism to enable execution for a particular region of memory. Under Windows, this is done by the VirtualProtect function. -- Curt Hagenlocher [email protected] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows Toolchain
Curt Hagenlocher hagenlocher.org> writes: > > The OS has to provide a mechanism to enable execution for a particular > region of memory. Under Windows, this is done by the VirtualProtect > function. More surprising is that Microsoft didn't whitelist their own toolchain. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows Toolchain
On Mon, Jul 13, 2009 at 2:55 PM, Antoine Pitrou wrote: > > Curt Hagenlocher hagenlocher.org> writes: >> >> The OS has to provide a mechanism to enable execution for a particular >> region of memory. Under Windows, this is done by the VirtualProtect >> function. > > More surprising is that Microsoft didn't whitelist their own toolchain. But dev tools don't actually execute the code they create in-process; they write the executable code out to disk and a new process is spun up from that image. So there should be no need to disable DEP for anything that the toolchain creates directly. Given that this was affecting multiple programs, the most likely culprit is either an anti-virus program or a virus -- though you probably can't rule out some kind of glitch in the OS itself. :/ -- Curt Hagenlocher [email protected] ___ Python-Dev mailing list [email protected] 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, 09 Jul 2009 01:22:19 -0700, Tarek Ziadé wrote: 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 ? I'll shortly send an email I composed regarding this. 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 ? I took a look at PEP 302 and Paul's new implemention in pkgutil2.py http://bitbucket.org/tarek/pep376/src/tip/pkgutil2.py And yes, I'd happy to try the new pkgutil API on PyPM .. keeping interoperability with pip/easy_install installed packages in mind. -srid ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 376 - from PyPM's point of view
Here are my comments regarding PEP 376 with respect to PyPM (the Python
package manager being developd at ActiveState)
Multiple versions: I understand that the PEP does not support
installation (thus uninstallation) of multiple versions of the same
package. Should this be explicitly mentioned in the PEP -- as
`get_distribution` API accepts only `name` argument, and not a `version`
argument?
get_distribution(name) -> Distribution or None.
Scans all elements in sys.path and looks for all directories ending
with .egg-info. Returns a Distribution corresponding to the .egg-info
directory that contains a PKG-INFO that matches name for the name
metadata.
Notice that there should be at most one result. The first result
founded is returned. If the directory is not found, returns None.
Some packages have package names with mixed case. Example: ConfigObj
.. as registered in setup.py. However, other packages such as turbogears
specifies "configobj" (lowercase) in their install_requires.
Is `get_distribution(name)` supposed to handle mixed cases? Will it
match both 'ConfigObj' and 'configobj'?
get_installed_files(local=False) -> iterator of (path, md5, size)
Will this also return the directories /created/ during the installation?
For example, will it also contain the entry "docutils" .. along with
"docutils/__init__.py"?
If not, how is the installer (pip, pypm, etc..) supposed to know which
directories to remove (docutils/) and which directories not to remove
(site-packages/, bin/, etc..)?
The new version of PEP 345 (XXX work in progress) extends the Metadata
standard and fullfills the requirements described in PEP 262, like the
REQUIRES section.
Can you tell more about this?
I see that PEP 262 allows both distributions names ('docutils') and
modules/packages ('roman.py') in the 'Requires:' section. Is this how
the new PEP is going to adhere to? Or, is it going to adhere to PEP
345's way of allowing *only* modules/packages?
In practice, I noticed that packages usually specify distribution names
in their 'Requires:' file (or install_requires.txt in the case of
setuptools). Hence, PyPM *assumes* the install requirements to be
distribution name. But then .. most distributions have the same name as
their primary module/package.
Ok, so PEP 345 also specifies the 'Provides:' header. Does
easy_install/pip make use 'Provides:' at all when resolving
dependencies? For example, does 'pip install sphinx' go look for all
distributions that 'provides' the 'docutils' provision.. or does it
simply get the distribution named 'docutils'?
-srid
___
Python-Dev mailing list
[email protected]
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 - from PyPM's point of view
--
http://www.ironpythoninaction.com
On 14 Jul 2009, at 01:12, "Sridhar Ratnakumar"
wrote:
Here are my comments regarding PEP 376 with respect to PyPM (the
Python
package manager being developd at ActiveState)
Multiple versions: I understand that the PEP does not support
installation (thus uninstallation) of multiple versions of the same
package. Should this be explicitly mentioned in the PEP -- as
`get_distribution` API accepts only `name` argument, and not a
`version`
argument?
get_distribution(name) -> Distribution or None.
Scans all elements in sys.path and looks for all directories ending
with .egg-info. Returns a Distribution corresponding to the .egg-info
directory that contains a PKG-INFO that matches name for the name
metadata.
Notice that there should be at most one result. The first result
founded is returned. If the directory is not found, returns None.
Some packages have package names with mixed case. Example: ConfigObj
.. as registered in setup.py. However, other packages such as
turbogears
specifies "configobj" (lowercase) in their install_requires.
Is `get_distribution(name)` supposed to handle mixed cases? Will it
match both 'ConfigObj' and 'configobj'?
An abomination for which I am truly sorry - however to be precise I'm
pretty sure the setup.py specifies configobj and it is only registered
on PyPI with mixed case (which I don't believe I can change).
Michael
get_installed_files(local=False) -> iterator of (path, md5, size)
Will this also return the directories /created/ during the
installation?
For example, will it also contain the entry "docutils" .. along with
"docutils/__init__.py"?
If not, how is the installer (pip, pypm, etc..) supposed to know which
directories to remove (docutils/) and which directories not to remove
(site-packages/, bin/, etc..)?
The new version of PEP 345 (XXX work in progress) extends the
Metadata
standard and fullfills the requirements described in PEP 262, like
the
REQUIRES section.
Can you tell more about this?
I see that PEP 262 allows both distributions names ('docutils') and
modules/packages ('roman.py') in the 'Requires:' section. Is this how
the new PEP is going to adhere to? Or, is it going to adhere to PEP
345's way of allowing *only* modules/packages?
In practice, I noticed that packages usually specify distribution
names
in their 'Requires:' file (or install_requires.txt in the case of
setuptools). Hence, PyPM *assumes* the install requirements to be
distribution name. But then .. most distributions have the same name
as
their primary module/package.
Ok, so PEP 345 also specifies the 'Provides:' header. Does
easy_install/pip make use 'Provides:' at all when resolving
dependencies? For example, does 'pip install sphinx' go look for all
distributions that 'provides' the 'docutils' provision.. or does it
simply get the distribution named 'docutils'?
-srid
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
