From: Fernando P. <Fer...@co...> - 2004-04-20 00:57:54
|
Hi all, I just installed PyX 0.6.2 on a clean system, but to a non-standard directory, using: python setup.py install --home=~/usr/local The installation went fine, and the lfs files (listed as data_files in setup.py) were correctly put in ~/usr/local/share/pyx. However, in usage, PyX won't find any of them, and I get error messages like: =========================================================================== In [4]: rho.coef_tree.draw_skeleton('foo') --------------------------------------------------------------------------- IOError Traceback (most recent call last) ? /home/fperez/research/code/mwadap/Function.py in __draw_skeleton_2d(self, fname, label, palette, fill) 489 r"$N_{nod}=%s, \epsilon=%1.1e, N_{blocks}=%s$" % 490 (self.nnod,self.cutoff,self.nkeys()), --> 491 [pyx.text.halign.center]) 492 493 # Generate eps file /home/fperez/usr/local/lib/python/pyx/canvas.py in text(self, x, y, atext, *args, **kwargs) 254 returns the inserted textbox""" 255 --> 256 return self.insert(self.texrunner.text(x, y, atext, *args, **kwargs)) 257 258 /home/fperez/usr/local/lib/python/pyx/text.py in text(self, x, y, expr, textattrs, texmessages) 1113 for i in range(lentextattrs): 1114 expr = textattrs[lentextattrs-1-i].apply(expr) -> 1115 self.execute(expr, self.defaulttexmessagesdefaultrun + self.texmessagesdefaultrun + texmessages) 1116 if self.texipc: 1117 if first: /home/fperez/usr/local/lib/python/pyx/text.py in execute(self, expr, texmessages) 861 raise IOError("file '%s' is not available or not readable. Available LaTeX font size files (*.lfs): %s" % (lfsname, lfsnames)) 862 else: --> 863 raise IOError("file '%s' is not available or not readable. No LaTeX font size files (*.lfs) available. Check your installation." % lfsname) 864 self.execute(lfsdef, []) 865 self.execute("\\normalsize%\n", []) IOError: file '10pt.lfs' is not available or not readable. No LaTeX font size files (*.lfs) available. Check your installation. =========================================================================== I've been able to solve the problem by hand, by copying the contents of ~/usr/local/share/pyx to ~/usr/local/lib/python/pyx/lfs. But this seems like an ugly solution to me. I don't know off-hand how to fix it, but somehow you guys will need to make the routine which searches for these files know where to look, even when the user installed to a different prefix. Regards, Fernando. ps. I'm loving pyx as it matures, keep up the good work! |
From: Andre W. <wo...@us...> - 2004-04-20 07:29:52
|
Hi, On 19.04.04, Fernando Perez wrote: > I've been able to solve the problem by hand, by copying the contents of > ~/usr/local/share/pyx to ~/usr/local/lib/python/pyx/lfs. But this seems > like an ugly solution to me. I don't know off-hand how to fix it, but > somehow you guys will need to make the routine which searches for these > files know where to look, even when the user installed to a different > prefix. Absolutely right. It was a bad design from the very beginning. We included ~/usr/local/lib/python/pyx/lfs only, because we needed it for CVS and local running (without using distutils and setup.py). When installing PyX via setup.py we really need to store the path to the share directory to have it available later on and do not include the ~/usr/local/lib/python/pyx/lfs anymore. I've patched setup.py accordingly and introduced a siteconfig.py (which is temporarily overwritten during install). IFAIK this is the solution to go. (Any distutils expert around?) We could step further and could define the "/etc/pyxrc" position along the same lines. The later is an open issue as well. André -- by _ _ _ Dr. André Wobst / \ \ / ) wo...@us..., http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript figures with Python & TeX (_/ \_)_/\_/ visit http://pyx.sourceforge.net/ |
From: Joerg L. <jo...@us...> - 2004-04-20 08:15:29
|
Hi, On 20.04.04, Andre Wobst wrote: > Absolutely right. It was a bad design from the very beginning. We > included ~/usr/local/lib/python/pyx/lfs only, because we needed it for > CVS and local running (without using distutils and setup.py). When > installing PyX via setup.py we really need to store the path to the > share directory to have it available later on and do not include the > ~/usr/local/lib/python/pyx/lfs anymore. I've patched setup.py > accordingly and introduced a siteconfig.py (which is temporarily > overwritten during install). Nice, although it's not clear why we do not only create the siteconfig.py file temporarily. In other words: why is there a siteconfig.py in the distribution, if it's just ignored by the installer. > IFAIK this is the solution to go. (Any distutils expert around?) We > could step further and could define the "/etc/pyxrc" position along > the same lines. The later is an open issue as well. +1 on including the pyxrc path in the siteconfig.py file Joerg -- JOERG LEHMANN | PyX - High quality PostScript figures with Python & TeX jo...@lu... | Visit http://pyx.sourceforge.net/ |
From: Andre W. <wo...@us...> - 2004-04-20 08:42:33
|
Hi, On 20.04.04, Joerg Lehmann wrote: > On 20.04.04, Andre Wobst wrote: > > I've patched setup.py > > accordingly and introduced a siteconfig.py (which is temporarily > > overwritten during install). > > Nice, although it's not clear why we do not only create the > siteconfig.py file temporarily. In other words: why is there a > siteconfig.py in the distribution, if it's just ignored by the > installer. First I thought (as well), that we would need that for our CVS developer version only. But you may download the distribution and use PyX without any install (you may add the PyX base directory to the PYTHONPATH or just run python in the base directory). Then you want our developer behaviour as well (otherwise we could just skip the distribution of siteconfig.py). I think it's fine -- its just an additional feature, that we can run PyX without any setup. Of course, we could do that path adjustment outside of siteconfig.py as well instead of replacing siteconfig.py. It would blow up the code, where we access the siteconfig, and thats actually worse to my eyes. Another issue is, that the lfs lives in a different directory than other shared material (pyx.def, textboxes.tex in the future -- which are distributed in contrib). Currently I've just left everything as it is. I'm not sure whether its worth any thoughts at all. In principal, the shared data material is different from other things we might distribute in contrib in the future (like a dvips.py). > +1 on including the pyxrc path in the siteconfig.py file What do you think about adding a flag to setup.cfg, where we enable the global pyxrc (this includes copying the pyxrc to the appropriate position) and denote the path of the global configuration in siteconfig.py (otherwise we could set this variable in siteconfig.py to None). I don't know whether its a good idea to make a global pyxrc an install option (I've never seen such a behaviour before). On the other hand we do not (yet) install the global pyxrc at all. This contradicts setting up the path of the global pyxrc during the install. Or should we switch to always install the global pyxrc? André -- by _ _ _ Dr. André Wobst / \ \ / ) wo...@us..., http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript figures with Python & TeX (_/ \_)_/\_/ visit http://pyx.sourceforge.net/ |
From: Joerg L. <jo...@us...> - 2004-04-20 09:03:30
|
Hi, On 20.04.04, Andre Wobst wrote: > First I thought (as well), that we would need that for our CVS > developer version only. But you may download the distribution and use > PyX without any install (you may add the PyX base directory to the > PYTHONPATH or just run python in the base directory). Then you want > our developer behaviour as well (otherwise we could just skip the > distribution of siteconfig.py). I think it's fine -- its just an > additional feature, that we can run PyX without any setup. Of course, > we could do that path adjustment outside of siteconfig.py as well > instead of replacing siteconfig.py. It would blow up the code, where > we access the siteconfig, and thats actually worse to my eyes. Ok, but then we should include a comment in the siteconfig.py file indicating that this file is ignored when PyX is being installed. > Another issue is, that the lfs lives in a different directory than > other shared material (pyx.def, textboxes.tex in the future -- which > are distributed in contrib). Currently I've just left everything as it > is. I'm not sure whether its worth any thoughts at all. In principal, > the shared data material is different from other things we might > distribute in contrib in the future (like a dvips.py). Sure, we have to think about the locations for these files at some point. > What do you think about adding a flag to setup.cfg, where we enable > the global pyxrc (this includes copying the pyxrc to the appropriate > position) and denote the path of the global configuration in > siteconfig.py (otherwise we could set this variable in siteconfig.py > to None). I don't know whether its a good idea to make a global pyxrc > an install option (I've never seen such a behaviour before). IMHO there is no reason for making this configurable. We should always install a global pyxrc file in the appropriate directory. The only open question is how to obtain this directory from distutils... Joerg -- JOERG LEHMANN | PyX - High quality PostScript figures with Python & TeX jo...@lu... | Visit http://pyx.sourceforge.net/ |
From: Andre W. <wo...@us...> - 2004-04-20 09:17:31
|
Hi, On 20.04.04, Joerg Lehmann wrote: > Ok, but then we should include a comment in the siteconfig.py file > indicating that this file is ignored when PyX is being installed. Fine, I'll do that. > > What do you think about adding a flag to setup.cfg, where we enable > > the global pyxrc (this includes copying the pyxrc to the appropriate > > position) and denote the path of the global configuration in > > siteconfig.py (otherwise we could set this variable in siteconfig.py > > to None). I don't know whether its a good idea to make a global pyxrc > > an install option (I've never seen such a behaviour before). > > IMHO there is no reason for making this configurable. We should always > install a global pyxrc file in the appropriate directory. The only open > question is how to obtain this directory from distutils... Ok, so lets modify setup.py to always install the global pyxrc. You can get "/etc" from distutils somehow (and you can set it to a different location like with "--home=..." or even within the setup.cfg). I'll take a look at it and do an implementation together with an enhancement of siteconfig.py. André -- by _ _ _ Dr. André Wobst / \ \ / ) wo...@us..., http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript figures with Python & TeX (_/ \_)_/\_/ visit http://pyx.sourceforge.net/ |
From: Fernando P. <Fer...@co...> - 2004-04-20 17:18:21
|
Andre Wobst wrote: > Absolutely right. It was a bad design from the very beginning. We > included ~/usr/local/lib/python/pyx/lfs only, because we needed it for > CVS and local running (without using distutils and setup.py). When > installing PyX via setup.py we really need to store the path to the > share directory to have it available later on and do not include the > ~/usr/local/lib/python/pyx/lfs anymore. I've patched setup.py > accordingly and introduced a siteconfig.py (which is temporarily > overwritten during install). IFAIK this is the solution to go. (Any > distutils expert around?) We could step further and could define the > "/etc/pyxrc" position along the same lines. The later is an open issue > as well. Thanks for addressing this. I noticed you are discussing the finer points of the solution, and running into the usual (and incredibly annoying) limitations of distutils. Good luck with that, it's driven me crazy in the past many times. distutils is great if you only want to do the trivial setup.py of their examples, but it sucks for more complicated things. In particular, getting information out of it (where it puts things, so your program can later know where to look for them) has always been frustrating to me (and it's undocumented as far as I know; reading the source code seems the only way of finding out). Best, and again many thanks for PyX. You have written a tool I'd been dreaming of for several years, but which I'd never had the time or the energy to write myself :) f |
From: Andre W. <wo...@us...> - 2004-04-21 05:50:34
|
Hi Fernando, On 20.04.04, Fernando Perez wrote: > Thanks for addressing this. I noticed you are discussing the finer points > of the solution, and running into the usual (and incredibly annoying) > limitations of distutils. I've seen you joining those discussions in the c.l.p and we had this issue together before as well (I think it was on this list). So let me briefly tell you, what solution I came up yesterday. Its not at all perfect, but I think it points into the correct direction to go. So first of all I decided we would need a siteconfig.py file, where I just store the path configuration. This is part of the pyx module, so it lives in the source tree. There is already a siteconfig.py in CVS and it will also be in the source distribution. It calculates path information relative to its current position, so you can start using PyX right from the CVS or from an unpacked source distribution. When installing PyX via distutils however, the siteconfig.py is not copied from the source tree, but a new one is created containing the actual install positions. I did this step within build_py, because this way I can just replace the copy operation by something else for this single file (this is slightly different from the solution I had first). The only disadvantage is, that you have to create a dependency of this build step from install_data to get the positions you need to write into siteconfig.py! (Obviously a better solution would be to create a install_siteconfig or the like, but it is more complicated to inject into distutils.) As far as I can see this solution works well and it obviously helps to fix the problem you had. It would be good to test this new install behaviour with a release candidate before the next release, so may be there are some volunteers around here, who would like to do so. I would appreciate testing on Windows at most, since I can do Linux (Debian) and Mac OS (fink) myself. But I do not like to build a test trunk for the new setup.py currently, because parts of PyX are broken the CVS due to development right now. Another thing would be to discuss this issue and the PyX solution we have now on sig-distutils or the like. Its obviously a general problem within distutils and its missing a standard solution. We might postpone that until we have some feedback from our new solution ... André -- by _ _ _ Dr. André Wobst / \ \ / ) wo...@us..., http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript figures with Python & TeX (_/ \_)_/\_/ visit http://pyx.sourceforge.net/ |
From: Fernando P. <Fer...@co...> - 2004-04-22 15:57:52
|
Hi Andre, Andre Wobst wrote: > Hi Fernando, > > On 20.04.04, Fernando Perez wrote: > >>Thanks for addressing this. I noticed you are discussing the finer points >>of the solution, and running into the usual (and incredibly annoying) >>limitations of distutils. > > > I've seen you joining those discussions in the c.l.p and we had this > issue together before as well (I think it was on this list). So let me > briefly tell you, what solution I came up yesterday. Its not at all > perfect, but I think it points into the correct direction to go. [snip] > Another thing would be to discuss this issue and the PyX solution we > have now on sig-distutils or the like. Its obviously a general problem > within distutils and its missing a standard solution. We might > postpone that until we have some feedback from our new solution ... While I see nothing in principle wrong with your solution, and I think it's a very reasonable approach for existing (up to python 2.3) installations, I would REALLY like to see the distutils developers make something like this much easier. The problem you are facing is a fairly standard one, and there's no reason why something like this should require such convoluted solutions. The distutils setup() function should simply have a standard way of leaving this information in the package installation directory. IMHO, setup() should always create a __setup__.py file in the package's top directory, containing a dictionary with all the values for the various paths which were _actually_ created, depending on what the user put in. This file should also have the possibility of being used by an automatic uninstall routine, by being a proper python script itself: #### hypothetical __setup__.py (not indented, typed in my mail client): setup_data = {'data_dir':'/home/foo/local/share', 'package_dir':'home/foo/local'} if __name__ == '__main__': import distutils import sys if sys.argv[1] == 'uninstall': distutils.uninstall(setup_data) ####################################################### If something as simple as this were done by distutils, we'd have: 1. A trivial way for any package to know where all of its stuff ended up splattered on the filesystem, so it can go later and find any of its own files. 2. An automatic, platform independent way to do uninstalls: $ python __setup__.py uninstall Any thoughts? Feel free to pass this message on to c.l.p or the distutils folks, if you like the idea. I'll have very limited computer access for a week or two starting tomorrow, so I won't be able to follow this further. However, I would very much like to see improvements on this fronts, distutils is IMHO one of python's few outright disastrous areas. Cheers, f |