Mailman 3 July 2001 - Distutils-SIG

Re: [Distutils] mac distutils needs more work
by Jack Jansen 13 Jul '01

13 Jul '01

Recently, "Pete Shinners" <pete(a)visionart.com> said: > first, distutils on macos does not know where its own > "site-packages" directory is. it actually asks the user > where it is when installing. with all the talk recently > on getting the install paths straightened out, i hope > this gets cleaned up on the macos side. This is the second report I hear of strange things with site-packages with MacPython, but I have absolutely no idea what the problem is. MacPython site-packages handling is identical to how unix does it, and it lives in the exact same place. As I'm not experiencing this problem I'd like to get into contact with people who have this problem. > the problem is that distutils cannot compile and libaries > that require linking to other libraries. it is very close, > but there are a couple "one-line" fixes needed to get it > working. I know about this problem, but (a) I have very little time and an enormous todolist, and (b) I don't know of any reasonably simple distutils-based packages that use the library (or application) targets. I posted a fairly detailed description to the pythonmac-sig yesterday of what would be needed to get mac-distutils to build library and app targets, if someone else could jump in that would be really nice... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

Distributing python applications
by Tessa Lau 13 Jul '01

13 Jul '01

I'm switching from autoconf to the distutils for building and installing my Python application. This application includes one pure-python package, one impure extension package, and various modules in the root package. I've figured most of it out except for two things that I used to do using autoconf: 1) Install two python scripts in a system-wide bin directory (not site-packages) 2) Create a new .py file by doing textual substitution on a .py.in file Suppose my program is called blarg. I want users to be able to run "blarg" from their command prompt. The file blarg is a python script that imports modules from blarg's library directory, which is usually something like ${exec_prefix}/lib/blarg-X.Y, where X.Y is the blarg version number. The reason I used textual substitution is so that I only have to change the version string in one place, and the same string is propagated to everyplace that needs it, including the two main application scripts that are installed in ${prefix}/bin. How can I do this using distutils? --Tessa

3 2

RE: Possible solution for PEP250 and bdist_wininst
by Moore, Paul 13 Jul '01

13 Jul '01

From: Thomas Heller [mailto:thomas.heller@ion-tof.com] > I have a possible solution for this problem. [Description cut] Sounds OK to me, but if I knew much about this area I'd have covered it in the PEP :-) One question: Should sys.extinstallpath be set for all platforms? Cleanrly, nothing but Windows will use it at present, but is there a meaningful value it could have on other platforms? If so, exposing it uniformly seems sensible. Paul.

2 1

RE: [Python-Dev] PEP 250 - site-packages on Windows: (Was: [Distu tils] Package DB: strawman PEP)
by Moore, Paul 13 Jul '01

13 Jul '01

From: Thomas Heller [mailto:thomas.heller@ion-tof.com] > The sources are in CVS: > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/distutils/misc/ Unfortunately, I don't have CVS access... > The bdist_wininst installer simply installs into prefix, > this is what the registry has under > HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.1\InstallPath. > > Now what should it do? What does that key *mean*? If it is the directory into which packages should get installed, then bdist_wininst should keep doing what it does now, and the Python installer should be changed to put site-packages into that key. If, on the other hand, this key has a meaning elsewhere in Python, and changing it would cause a problem, then I would say that this is a bug in the Windows Installer, which should use a key of its own. In that case, my recommendation would be to have the Python 2.2 installer create a new key, and wininst use that if it exists, otherwise fall back to the current key. That would provide the correct behaviour in the new release, but retain backward compatibility with earlier versions of Python. > There are probably some issues here. Agreed. I apologise if I didn't publicise the PEP in the right places for these to get picked up earlier - I thought I had. I believe my suggestion above will do the right thing, but I am not an expert in the intricacies of Python's use of the registry, so I'd like someone more knowledgeable to comment, if possible. Paul.

4 4

PEP 250 - site-packages on Windows: (Was: [Distutils] Package DB: strawman PEP)
by Moore, Paul 12 Jul '01

12 Jul '01

From: Pete Shinners [mailto:pete@shinners.org] > for the love of all things good, can we please make a recommendation > in our PEP that the windows installation location be something other > than "C:\PYTHON21"? something like "C:\PYTHON21\SITE-PACKAGES" would > be a big improvement. i thought i heard that macpython recently made > this "fix", why is the windows version lagging on this? PEP 250 covers this. I have sent in the final PEP for approval, plus a patch, but the process appears to be stalled. I guess I need to nag again. The PEP process doesn't seem to cover non-core Python developers well (eg, people like me who don't have a way of integrating with the Sourceforge mechanisms...) Paul.

9 11

RE: [Python-Dev] PEP 250 - site-packages on Windows: (Was: [Distu tils] Package DB: strawman PEP)
by Moore, Paul 12 Jul '01

12 Jul '01

From: M.-A. Lemburg [mailto:mal@lemburg.com] > They should be in the CVS tree of Python on SourceForge. I don't have CVS access, so I can't get at these, unfortunately... > About the change: I think distutils should lookup the path in Python's > site.py file - that way you assure that distutils will work on all > Python installations rather than only on those which have the site.py > patch. Otherwise, Python won't find the packages installed in > Lib/site-packages. I'm not sure what you intend, here. site.py doesn't export this directory - it is just one of the directories which gets added to sys.path in site.py. On Unix, there are more than one such directory (both version-specific and version-independent), so there isn't, in general, just one such directory. I don't know how you could encapsulate this in a way which would not clash with other platforms' policies. The intention of this change was to be the smallest possible change which would work. I believe it (or at least, the patch I sent when I submitted the final version of the PEP) does that for everything except the Windows Installer. I'll have to defer judgement on how best to address that area to others better qualified to comment, but see my message to Thomas for my suggestion. Hope this helps, Paul.

3 3

RE: [Python-Dev] PEP 250 - site-packages on Windows: (Was: [Distu tils] Package DB: strawman PEP)
by Moore, Paul 12 Jul '01

12 Jul '01

From: M.-A. Lemburg [mailto:mal@lemburg.com] > I don't have a site-packages dir in my installations. Could it be that > you installed some distutils package which automagically created one > or that this change in Python 2.1.1 ? I don't believe so. I have ActiveState Python - it's possible (although unlikely, I would think) that that version creates site-packages specially. It's vaguely possible (although unlikely) that I created the directory manually - it was missing in one of the 2.1 betas, IIRC, but I thought it reappeared in 2.1 final. In any case, the necessary changes to make sure that directory exists should be in the Windows Installer package(s) for Python. I guess that means somewhere in the Wise installer scripts - which I don't have access to, nor would I know how to change. It should just be a case of reinstating the behaviour in 2.0, if the directory really has been lost in 2.1. > This doesn't seem to do the trick: the Windows installer still installs > the packages directly to \Python21. This change should (as I said, it's untested) have ensured that "python setup.py install" puts the module into site-packages. I don't know what the installer code in bdist_wininst.py does, as it's a base64-encoded EXE, and I don't have the sources - surely it uses the distutils sysconfig stuff to get the value (it has no other way of knowing...)? Paul.

4 3

企业上网，一步到位(Your online company)
by wwwjessie＠21cn.com 12 Jul '01

12 Jul '01

尊敬的会员，您好！壹食品中国网服务信息供您参考：拥有自己的网上公司，展示公司产品和服务，提高企业竞争力,您有两种选择： 1/ 网站定制 <http://www.ifood1.com/aboutus/ourservices/web.asp> : 自己维护更新，管理前台后台，根据企业需要，建立自己的网上公司，数据库模块任您选择：商情信息发布,网上产品展示，客户服务中心,网上购物系统,客户关系管理,网上论坛,网上会议中心,网上招聘,投票系统,资料下载中心,问卷调查, 招标采购系统,访问者统计分析, 聊天室(交流、谈判)…… 想了解数据库模块演示中心？请联系： sales(a)ifood1.com <mailto:sales@ifood1.com> 　电话：0755-3786309　销售部沈小姐 2/ 壹网通 <http://onet.ifood1.com/> -自助式建网，操作简单，即建即用：可展示30张或更多照片，自助式维护，可随时更新图片和文字内容，在线发布产品信息、公司动态等，赠送二级国际域名( 如http://yourname.ifood1.com)，与壹食品中国网(页面浏览量月逾200万次)紧密连接，提高买家和顾客访问量，定期收到壹食品中国网提供的客户需求和采购信息。 7月30日前申请并付款使用壹网通，特别优惠价3800元/年，赠送条码广告并免费在食品专业杂志刊登供，求，代理，合作信息想了解更多? 　请联系： sales(a)ifood1.com <mailto:sales@ifood1.com> 　电话：0755-3786309　　销售部沈小姐或访问我们的网页 <http://www.ifood1.com/aboutus/ourservices/cpservice.asp> :www.ifood1.com 回执（请传真：0755-3239047或发电子邮件： sales(a)ifood1.com <mailto:sales@ifood1.com> ） □ 本公司对网站定制感兴趣　　 □ 本公司对壹网通服务感兴趣公司名称：_____________________________________________联系人：__________________ _____ 电话：_____________________传真：______________________E-mail：________________ ______

1 0

RE: [Python-Dev] PEP 250 - site-packages on Windows: (Was: [Distu tils] Package DB: strawman PEP)
by Moore, Paul 12 Jul '01

12 Jul '01

From: M.-A. Lemburg [mailto:mal@lemburg.com] Tim Peters wrote: > Umm, what am I missing? The change to site.py was so simple you could have > committed it yourself quicker than it took to write the above. I committed > it a few minutes ago. If something else is needed, someone else will have > to do it (or explain it to me in detail so precise they could do it themself > 10x quicker <wink>). > Cool, but what about the changes needed in distutils to actually > utilize the new directory and the changes to the Windows installer > to create the directory at installation time ? The patch I sent along with the final version of the PEP included the distutils change (it's only one line, but it's on the PC at home, so I can't quote it here). I assume that the Python install should ensure that the site-packages exists (it does at the moment) so I don't see a need for the wininst installer to check. Paul. PS [After a quick rummage...] I *think* the following patch is what is needed for distutils: I haven't tested it, though, so it would be better to check the original version (which I did test...) --- sysconfig.py.orig Thu Apr 19 10:24:24 2001 +++ sysconfig.py Thu Jul 12 09:32:34 2001 @@ -87,7 +87,7 @@ elif os.name == "nt": if standard_lib: - return os.path.join(PREFIX, "Lib") + return os.path.join(PREFIX, "Lib", "site-packages") else: return prefix

2 1

Re: [Distutils] Package DB: strawman PEP
by Mats Wichmann 12 Jul '01

12 Jul '01

At 02:33 PM 7/9/2001 -0400, Mark W. Alexander wrote: >On Sun, 8 Jul 2001, Andrew Kuchling wrote: > >> It seems time to bite the bullet and actually begin designing and >> implementing a database of installed packages. As a strawman to get a >> focused discussion started, here's a draft of a PEP, with lots of >> XXX's in it. Followups to the Distutils SIG, please. > >I'm confused. Why? What does this give us that native package managers >don't. How is it going to keep synchronized with package manager? One problem is that native package managers don't make sense for everything. I can't imagine wanting to even deal with many of the package managers out there for a smaller Python package. I'm not even convinced that one of the major entrants out there - the Windows one - does a reasonable job with dependencies, but I'm pretty ignorant there. And even small packages - a few Python source files - might want to check for prereqs.

4 3