pyx-devel — PyX development

Re: [PyX-devel] Re: "smoothed" attribute in PyX

[Michael S. <m-s...@us...>]

Hello Peter and André,

On 06.12.04, Andre Wobst wrote:
> > Finally, the diagrams have wiggly lines (roughly sinusoidal) attached 
> > at either end to represent the velocity operator. It would be great if 
> > there were a "deformer" which give a wiggly line instead of a cycloid. 
> > Are there plans to extend the "deformer" functions in the future?

Please note that lots of "wiggly" lines can be thought of. A cycloid
might look like a sinusoidally wiggled curve if you stretch it
tremendously. A precise sinus is something different, however.

The main problem with deformers that try to implement a well-defined
geometrical thing like a cycloid or a sinus is how to cope with the
curvature of the underlying curve. This is something I tried to
optimize in the cycloid, and which makes it quite hard to understand
(I guess).

More deformers with sinus, zig-zag, ... would be nice.

> There's another thing worth some thoughts in the design phase of such
> a "framework" for feynman diagrams. Stroking arrows at the paths (at
> the end or in the middle of a path) should be straight forward. Such
> an arrow would be a decorator, not a deformer, by the way. But what I
> would take care of from the very beginning are those double lines. I'm
> not totally sure how those should be created starting from a
> connecting path in the beginning. Should we start to have two paths
> for that case. I don't think so ... but I do not have strong arguments
> at hand.

Do you mean to parallel curves with constant distance to each other?
You certainly remember our discussion on the problem of "extending"
curved boxes this way. This is, again, the same problem -- and it is a
hard one.

Michael.

-- 
"A mathematician is a device for turning coffee into theorems"
  Paul Erdös.

Re: [PyX-devel] PyX Fink package.

[Gert I. <Ger...@Ph...>]

Hi,

> Thus I'm confident that I could spend some time in preparing 0.7.1
> over the weekend or early next week. And I think it would be worth the

ok, then I will try to come up with a solution for the faq beginning of
next week.

Best regards,
Gert

--=20
 Gert-Ludwig Ingold        email: Ger...@Ph...
 Institut f=FCr Physik       Phone: +49-821-598-3234
 Universit=E4t Augsburg      Fax  : +49-821-598-3222
 D-86135 Augsburg          WWW  : www.physik.uni-augsburg.de/theo1/ingold
 Germany                   PGP  : 86FF5A93, key available from homepage

[PyX-devel] Re: "smoothed" attribute in PyX

[Andre W. <wo...@us...>]

Hi Peter,

On 30.11.04, Peter Falloon wrote:
> Thanks for that, everything works again now! Meanwhile, I hate to 
> bother you again, but I've decided to try and create a set of feynman 
> diagrams (of the kind used to calculate weak localization etc, i.e. 
> cooperons and diffusons and so on). I think ultimately getting a good 
> set of diagrams would be a very useful application of pyx. The first 
> step is to create an oval-shaped curve. I've been looking but I don't 
> see a simple way to do this. Ideally, there would be an optional extra 
> argument to circle which would allow to elongate along x or y axis. The 
> other option, which seems much less elegant, is to perform a linear 
> transformation on the circle, but this doesn't seem to work. Is there a 
> simple way to generate an oval?

No. Its actually what PostScript offers (IIRC). If you want to draw an
elipse, you have to transform a circle. However, you can also use
bezier curves to nicely build those kind of shapes.

> Finally, the diagrams have wiggly lines (roughly sinusoidal) attached 
> at either end to represent the velocity operator. It would be great if 
> there were a "deformer" which give a wiggly line instead of a cycloid. 
> Are there plans to extend the "deformer" functions in the future?

(I basically do know how feynman diagrams look like and I even do
understand in principle what they stand for -- thanks to Gert!)

There are several things to be addressed here. You want to connect
nodes. This is something you could make use of connectors. Those nodes
are called boxes in the (current) language of PyX. These are graphical
objects with a border, where we currently have a limitation to
polygons but this is subject of change for the future (i.e. circles
and the like should become possible in the future). As soon as you
have connection lines, you could take advantage of deformers to create
those wiggled lines. (It actually funny, that the cycloid, as we have
it now, was originally a replacement for a wiggler (which I
mistakeably called wriggler in my implementation) I wrote almost a
year ago. It was more or less a design test and an example of what
kind of path operations I had in mind that time. I was concentrating
on a spring-like design as the real cycloid does it now as well.)

The wiggler deformer, as you would like to have it, should be a
different deformer than the cycloid. I think its not a good idea to
build one huge and complicated deformer which is a huge collection of
all kind of strange deform operations. Instead, we should have several
small and handy deformers (also in terms of there parameter list),
which OTOH could share some code by inheritance between each other.

There's another thing worth some thoughts in the design phase of such
a "framework" for feynman diagrams. Stroking arrows at the paths (at
the end or in the middle of a path) should be straight forward. Such
an arrow would be a decorator, not a deformer, by the way. But what I
would take care of from the very beginning are those double lines. I'm
not totally sure how those should be created starting from a
connecting path in the beginning. Should we start to have two paths
for that case. I don't think so ... but I do not have strong arguments
at hand.

Since Michael has spend quite some time in writing the connectors and
the cycloid deformer, we might get him (and possibly others) included
in the discussion. Thus I'm just cross-posting this answer to
pyx-devel. Take it into account when answering, that Peter might not
(yet ;-)) be a subscriber of pyx-devel ...


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

Re: [PyX-devel] PyX Fink package.

[Andre W. <wo...@us...>]

Hi,

On 06.12.04, Andre Wobst wrote:
> Could we summarize a bit, what we should take care off before
> releasing? The tipa issue. Sure. Other things, which somebody has in
> the queue?

I just realized that about a week ago somebody asked me for an example
on how to use error bars. I came up with a slightly modified version
of minimal.py. I just enclose it here. I'm not so sure whether its
worth to be included. I just don't have a clear feeling on the value
what this example has to a beginner. In principle I think we should
avoid to have several examples showing the same features ...

Comments?


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

Re: [PyX-devel] PyX Fink package.

[Andre W. <wo...@us...>]

Hi,

On 03.12.04, Andrea Riciputi wrote:
> >In principle, I would also like to release a new version, but I know
> >that André has a lot of work to do at the moment. In principle, I could
> >also prepare the release alone. But this may not be the best idea
> >because my PyX release experience lately became a little bit rusty.

While I was completely blocked during the last weeks due to some
conference organization and performing the copy deadline for the
abstract books (the conference consists of 6200+ contributions and the
conference booklet does actually consist of 5 parts), I see the end of
the work at the horizon and expect to get everything out to the print
office by the end of this week.

Thus I'm confident that I could spend some time in preparing 0.7.1
over the weekend or early next week. And I think it would be worth the
effort, since we accumulated some patches and we do have this missing
INDEX file issue in the current release (which was new in this
release). Although we managed to don't have some real show-stoppers in
the current release, a polishing release might be a good idea, since
it will take some time to work out some of the future goals to get a
real new release.

Could we summarize a bit, what we should take care off before
releasing? The tipa issue. Sure. Other things, which somebody has in
the queue? (I do have some enhancements of the pdfwriter in a private
development tree, which basically enhances the pdfwriter to what we
had in our first experiments in pdf writing (creating text etc.). I
could commit that, but it doesn't really matter. I didn't had time to
continue the development lately. In order to keep the release close to
what we had, I think its better to keep it off.)


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

Re: [PyX-devel] PyX Fink package.

[Andre W. <wo...@us...>]

Hi,

On 06.12.04, Gert Ingold wrote:
> > If there is not any other "more" standard package to produce phonetic
> > transliteration, the png solution it should be ok.
> 
> tipa is usually considered to be *the* package for phonetic typesetting.
> I will try to come up with a working png solution. (Andre, Jörg: do you
> agree?)

I totally agree. And I do not really like the idea to give up tipa due
to the dependency it creates for *building* a package. (I think the
final package would not need to have this dependency.) For the
official build as we distribute it on the PyX webpage (note that we
decided to skip distributing the compiled manual and faq within the
distribution to greatly reduce its memory footprint after some
discussion on this list or the users list -- I don't remember exactly)
I would like to keep the tipa solution.

However, I see the point of wanting a tipa-free ability to generate a
almost optimal form of the faq. There are two possibilities: allow for
a build by just skipping the phonetic transliterations or generate
png's (pdf's?) for the usecases we need and include it in the
distribution. The pdf-solution, when it's possible, might be a way to
completely remove the tipa dependency as soon as you have the pdf
snipplets, which we could include in the distribution. This might be a
way out of splitting the faq-generation into an full and a poor man's
solution. Somebody how wants to try whether this option is not just a
rash thought?


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

Re: [PyX-devel] PyX Fink package.

[Gert I. <Ger...@Ph...>]

Hi,

> If there is not any other "more" standard package to produce phonetic
> transliteration, the png solution it should be ok.

tipa is usually considered to be *the* package for phonetic typesetting.
I will try to come up with a working png solution. (Andre, J=F6rg: do you
agree?)

Best regards,
Gert

--=20
 Gert-Ludwig Ingold        email: Ger...@Ph...
 Institut f=FCr Physik       Phone: +49-821-598-3234
 Universit=E4t Augsburg      Fax  : +49-821-598-3222
 D-86135 Augsburg          WWW  : www.physik.uni-augsburg.de/theo1/ingold
 Germany                   PGP  : 86FF5A93, key available from homepage

Re: [PyX-devel] PyX Fink package.

[Andrea R. <ari...@pi...>]

On 3 Dec 2004, at 16:32, Gert Ingold wrote:

> would three small png's which could be inserted as figures be an
> option?

If there is not any other "more" standard package to produce phonetic 
transliteration, the png solution it should be ok.

Andrea.

Re: [PyX-devel] PyX Fink package.

[Joerg L. <jo...@us...>]

On 03.12.04, Andrea Riciputi wrote:
> No, there is not any deadline. I wanted just to know because if the new 
> release will come out in matter of months I can consider to create a 
> Fink package that includes all the patches (a sort of CVS snapshot), 
> but it would be very time consuming for me. On the other hand if the 
> new release will come out in a matter of days (or weeks) I can revert 
> Fink package to version 0.6.3 and wait for the new version. That's it.

I don't think there is any need to revert to an older version. IMHO, the
bugs which have shown up so far are all not critical. Concerning the
question of a 0.7.1 release, I think it's realistic that we'll prepare a
release within the next one or two weeks.

        Jörg

Re: [PyX-devel] PyX Fink package.

[Gert I. <Ger...@Ph...>]

Hi,

> Both solutions seem unsatisfactory to me, so I'm wondering if it should=
=20
> be possible to make FAQ file not require tipa.sty (after all it is only=
=20
> for 3 phonetic transliterations). Furthermore AFAIK all teTeX users=20
> would experiment the same problem and they would be forced to install=20
> tipa package or to download the FAQ.pdf file directly from PyX site.

would three small png's which could be inserted as figures be an
option?

Best regards,
Gert

--=20
 Gert-Ludwig Ingold        email: Ger...@Ph...
 Institut f=FCr Physik       Phone: +49-821-598-3234
 Universit=E4t Augsburg      Fax  : +49-821-598-3222
 D-86135 Augsburg          WWW  : www.physik.uni-augsburg.de/theo1/ingold
 Germany                   PGP  : 86FF5A93, key available from homepage

Re: [PyX-devel] PyX Fink package.

[Andrea R. <ari...@pi...>]

No, there is not any deadline. I wanted just to know because if the new=20=

release will come out in matter of months I can consider to create a=20
Fink package that includes all the patches (a sort of CVS snapshot),=20
but it would be very time consuming for me. On the other hand if the=20
new release will come out in a matter of days (or weeks) I can revert=20
Fink package to version 0.6.3 and wait for the new version. That's it.

Cheers,
   Andrea.

P.S.: I'll look forward for any comments from Gert about the FAQ.

On 3 Dec 2004, at 16:00, Joerg Lehmann wrote:

> In principle, I would also like to release a new version, but I know
> that Andr=E9 has a lot of work to do at the moment. In principle, I =
could
> also prepare the release alone. But this may not be the best idea
> because my PyX release experience lately became a little bit rusty.
>
> Is there any deadline concerning a Fink release?
>
>         J=F6rg

Re: [PyX-devel] PyX Fink package.

[Joerg L. <jo...@us...>]

Hi Andrea,

On 03.12.04, Andrea Riciputi wrote:
> I had prepared and already submitted the Fink package for PyX 0.7 when 
> I realized that there are some problem with it. Many of these problems 
> have been discussed on the lists in the last days and Andre and Jörg 
> have submitted the required patches. The last problem that some Fink 
> users have made me aware of was related to the compilation of the FAQ. 
> They require tipa.sty that is not included in standard teTeX 
> distribution, letting me with only two solutions:
> 
> 1) don't compile FAQ file
> 
> 2) create a new Fink package for tipa and make Pyx Fink package depends 
> on it
> 
> Both solutions seem unsatisfactory to me, so I'm wondering if it should 
> be possible to make FAQ file not require tipa.sty (after all it is only 
> for 3 phonetic transliterations). Furthermore AFAIK all teTeX users 
> would experiment the same problem and they would be forced to install 
> tipa package or to download the FAQ.pdf file directly from PyX site.

I'll leave this decision up to Gert who maintains the FAQ.

> With this and all other issues arised in last days, are you considering 
> to release a bug-fix version of PyX within next days? If so I would 
> consider to wait until that version comes out to create the new Fink 
> package...

In principle, I would also like to release a new version, but I know
that André has a lot of work to do at the moment. In principle, I could
also prepare the release alone. But this may not be the best idea
because my PyX release experience lately became a little bit rusty.

Is there any deadline concerning a Fink release?

        Jörg

[PyX-devel] PyX Fink package.

[Andrea R. <ari...@pi...>]

Hi,
I had prepared and already submitted the Fink package for PyX 0.7 when=20=

I realized that there are some problem with it. Many of these problems=20=

have been discussed on the lists in the last days and Andre and J=F6rg=20=

have submitted the required patches. The last problem that some Fink=20
users have made me aware of was related to the compilation of the FAQ.=20=

They require tipa.sty that is not included in standard teTeX=20
distribution, letting me with only two solutions:

1) don't compile FAQ file

2) create a new Fink package for tipa and make Pyx Fink package depends=20=

on it

Both solutions seem unsatisfactory to me, so I'm wondering if it should=20=

be possible to make FAQ file not require tipa.sty (after all it is only=20=

for 3 phonetic transliterations). Furthermore AFAIK all teTeX users=20
would experiment the same problem and they would be forced to install=20
tipa package or to download the FAQ.pdf file directly from PyX site.

With this and all other issues arised in last days, are you considering=20=

to release a bug-fix version of PyX within next days? If so I would=20
consider to wait until that version comes out to create the new Fink=20
package...

Any comments?

  Andrea.

Re: [PyX-devel] INDEX file.

[Andrea R. <ari...@pi...>]

Thanks J=F6rg,
I was preparing the Fink package for pyx. At the moment it's easier for=20=

me to leave it as it is and I'll fix it when the next release will come=20=

out.

Cheers,
   Andrea.

On 2 Dec 2004, at 22:16, Joerg Lehmann wrote:

> Yes, it's a known issue which is already fixed in CVS. At the moment,
> you have to get the INDEX files from the CVS repository, but note that
> they contain a new example (julia.py) which is not contained in the =
PyX
> 0.7 release.
>
>         J=F6rg

Re: [PyX-devel] INDEX file.

[Joerg L. <jo...@us...>]

Hi Andrea,

On 02.12.04, Andrea Riciputi wrote:
> I don't know if it is an already known issue or not, but I've not found 
> any mention on the list. I've noticed that the INDEX file that is 
> supposed to be in /example dir is not included in the PyX-0.7 tarball. 
> Hence the related Makefile does not work at all.

Yes, it's a known issue which is already fixed in CVS. At the moment,
you have to get the INDEX files from the CVS repository, but note that
they contain a new example (julia.py) which is not contained in the PyX
0.7 release.

        Jörg

[PyX-devel] INDEX file.

[Andrea R. <ari...@pi...>]

Hi,
I don't know if it is an already known issue or not, but I've not found 
any mention on the list. I've noticed that the INDEX file that is 
supposed to be in /example dir is not included in the PyX-0.7 tarball. 
Hence the related Makefile does not work at all.

HTH,
   Andrea.

[PyX-devel] [ pyx-Bugs-1071160 ] PyX on cygwin: `CRLF' EOL token not handled properly

[SourceForge.net <no...@so...>]

Bugs item #1071160, was opened at 2004-11-22 18:50
Message generated for change (Settings changed) made by joergl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1071160&group_id=45430

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Hans-Andreas Engel (hansres)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyX on cygwin: `CRLF' EOL token not handled properly

Initial Comment:
When PyX runs on cygwin and calls `kpsewhich' from
MikTeX, CRLFs ("\r\n") are returned as end-of-line
tokens.  This is not recognized at the moment and
results in the following error. 
  IOError: [Errno 2] No such file or directory: 
 
'C:/Progra~1/MikTeX/localtexmf/dvips/config/psfonts.map\r'

A trivial fixed is provided in the attached patch.

----------------------------------------------------------------------

>Comment By: Jörg Lehmann (joergl)
Date: 2004-11-22 21:47

Message:
Logged In: YES 
user_id=390410

Hi Hansres,

thanks for the patch, which besides fixing this porability issue
makes the code more readable. I've just checked it in.

    Jörg

 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1071160&group_id=45430

[PyX-devel] [ pyx-Bugs-1071160 ] PyX on cygwin: `CRLF' EOL token not handled properly

[SourceForge.net <no...@so...>]

Bugs item #1071160, was opened at 2004-11-22 12:50
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1071160&group_id=45430

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Hans-Andreas Engel (hansres)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyX on cygwin: `CRLF' EOL token not handled properly

Initial Comment:
When PyX runs on cygwin and calls `kpsewhich' from
MikTeX, CRLFs ("\r\n") are returned as end-of-line
tokens.  This is not recognized at the moment and
results in the following error. 
  IOError: [Errno 2] No such file or directory: 
 
'C:/Progra~1/MikTeX/localtexmf/dvips/config/psfonts.map\r'

A trivial fixed is provided in the attached patch.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1071160&group_id=45430

[PyX-devel] [ pyx-Bugs-1070285 ] use CURDIR instead of PWD in Makefiles

[SourceForge.net <no...@so...>]

Bugs item #1070285, was opened at 2004-11-21 03:18
Message generated for change (Comment added) made by wobsta
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1070285&group_id=45430

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: David M. Cooke (dmcooke)
Assigned to: Nobody/Anonymous (nobody)
Summary: use CURDIR instead of PWD in Makefiles

Initial Comment:
examples/Makefile and manual/Makefile both use PWD when
setting PYTHONPATH. This breaks when -C is used with
make. For instance, in the root PyX directory, executing

$ echo $PWD
/home/cookedm/src/Pyx-0.7
$ make -C examples pdf

will fail building hello.py because PYTHONPATH is set
to '/home/cookedm/src/Pyx-0.7/..'. PWD is taken from
the shell environment, whereas make sets CURDIR to the
correct current directory.


----------------------------------------------------------------------

>Comment By: André Wobst (wobsta)
Date: 2004-11-22 17:42

Message:
Logged In: YES 
user_id=405853

I see. I was not aware of the difference. It is fixed in CVS now. Thanks 
for reporting ...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1070285&group_id=45430

[PyX-devel] [ pyx-Bugs-1070285 ] use CURDIR instead of PWD in Makefiles

[SourceForge.net <no...@so...>]

Bugs item #1070285, was opened at 2004-11-20 21:18
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1070285&group_id=45430

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David M. Cooke (dmcooke)
Assigned to: Nobody/Anonymous (nobody)
Summary: use CURDIR instead of PWD in Makefiles

Initial Comment:
examples/Makefile and manual/Makefile both use PWD when
setting PYTHONPATH. This breaks when -C is used with
make. For instance, in the root PyX directory, executing

$ echo $PWD
/home/cookedm/src/Pyx-0.7
$ make -C examples pdf

will fail building hello.py because PYTHONPATH is set
to '/home/cookedm/src/Pyx-0.7/..'. PWD is taken from
the shell environment, whereas make sets CURDIR to the
correct current directory.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1070285&group_id=45430

Re: [PyX-devel] Installing PyX to a non-standard location.

[Andrea R. <ari...@pi...>]

Sorry for the double post, but I've realized that if I change 
data_files removing the leading / in the pyxrc line:

-               ("/etc", ["pyxrc"])]
+               ("etc", ["pyxrc"])]

the file will be installed relative to the dir given in the --home 
options, instead of the dir given in --root as is the case of share/pyx 
dir. Although I don't give the --home option explicitly, it works 
anyway. Don't ask me why... ;-)

Since my installation command is:

python install --root=%d

where %d expands at installation time to 
'/sw/src/root-pyx-wierda-py23-0.7-10', I can imagine that distutils (or 
more probably Fink) are able to understand that they have to subtract 
this dir from the installation path.

Any way the point is that simply removing the leading "/" fix the 
problem related to the directory in which pyxrc is written. Now the 
point is if this fix works on other platforms as well or if it is Fink 
specific. In the former case I think you can put it in the CVS, while 
in the latter case I'll keep it in the Fink's patch file. Let me know 
your opinions about this.

Regarding the problem related to siteconfig.py file, the previous patch 
is the easier way I can see to get the right paths written in it.

Eventually, as I said in the previous email, I'll look in the share and 
doc issue next week-end.

Cheers,
   Andrea.


On 18 Nov 2004, at 10:43, Andrea Riciputi wrote:

> On 18 Nov 2004, at 08:50, Andre Wobst wrote:
>
>> Oh my goodness.
>>
>> What I don't understand upto now is, why the pyxrc gets installed to
>> "/etc". In step 4 above everything is fine. With the siteconfig below
>> it should work on this installation position. Couldn't you do this by
>> using the distutils install command with the proper --root and
>> --prefix and without any patch? Then everything is fine, and you could
>> copy it to the final location ... only the siteconfig.py would be
>> needed to be adjusted (since you copy it around).
>
> I'vee tried your suggestion using both --root and --prefix but it 
> doesn't work. The problem here is that dpkg installs files following 
> the tree rooted to the directory given through --root option, not to 
> the directory given through --prefix option. May be an example makes 
> this clear: if --root is /foo/bar then dpkg will discharge this prefix 
> from the installation path, so that a file that is under 
> /foo/bar/foofoo/barbar will be installed in /foofoo/barbar.
>
> Since --root is '/sw/src/root-pyx-wierda-py23-0.7-6', pyxrc will be 
> written in /etc instead that in /sw/etc. As far as I can understand if 
> you want to make your setup script to works without patch with fink 
> you must take your paths relative to --prefix and not to --root. But I 
> don't know if this could work well on other platforms. Anyway I think 
> it would be better (and even simpler for you) to keep the setup.py 
> script as general as possible (I mean not too much targeted to a 
> specific platform) and let those who have special needs to patch it. 
> My 2 cents though...
>
>>> Evetually the @PYTHON_FLAVOR@ is mandatory because Fink still has
>>> Python 2.2 and 2.3 flavours and a user may want to have both 
>>> installed.
>>
>> I see. You want to get the shared data installed twice although it
>> does not depend on the Python version (and the plattform). But thats
>> not what shared data are for. While, ok, you can do it that way,
>> another idea would be to make a python-pyx-common package for the
>> share data (and a python-pyx-doc for the documentation) and some
>> python2.x-pyx packages for the Python scripts. Ok, its a bit overkill,
>> but the debian packages do it that way.
>
> You are right, I could create two splitoff for the package one for the 
> docs and one for the shared datas. I'll try if it is feasible this 
> week-end.
>
> Andrea.
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: InterSystems CACHE
> FREE OODBMS DOWNLOAD - A multidimensional database that combines
> robust object and relational technologies, making it a perfect match
> for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
> _______________________________________________
> PyX-devel mailing list
> PyX...@li...
> https://lists.sourceforge.net/lists/listinfo/pyx-devel
>

Re: [PyX-devel] Installing PyX to a non-standard location.

[Andrea R. <ari...@pi...>]

On 18 Nov 2004, at 08:50, Andre Wobst wrote:

> Oh my goodness.
>
> What I don't understand upto now is, why the pyxrc gets installed to
> "/etc". In step 4 above everything is fine. With the siteconfig below
> it should work on this installation position. Couldn't you do this by
> using the distutils install command with the proper --root and
> --prefix and without any patch? Then everything is fine, and you could
> copy it to the final location ... only the siteconfig.py would be
> needed to be adjusted (since you copy it around).

I'vee tried your suggestion using both --root and --prefix but it 
doesn't work. The problem here is that dpkg installs files following 
the tree rooted to the directory given through --root option, not to 
the directory given through --prefix option. May be an example makes 
this clear: if --root is /foo/bar then dpkg will discharge this prefix 
from the installation path, so that a file that is under 
/foo/bar/foofoo/barbar will be installed in /foofoo/barbar.

Since --root is '/sw/src/root-pyx-wierda-py23-0.7-6', pyxrc will be 
written in /etc instead that in /sw/etc. As far as I can understand if 
you want to make your setup script to works without patch with fink you 
must take your paths relative to --prefix and not to --root. But I 
don't know if this could work well on other platforms. Anyway I think 
it would be better (and even simpler for you) to keep the setup.py 
script as general as possible (I mean not too much targeted to a 
specific platform) and let those who have special needs to patch it. My 
2 cents though...

>> Evetually the @PYTHON_FLAVOR@ is mandatory because Fink still has
>> Python 2.2 and 2.3 flavours and a user may want to have both 
>> installed.
>
> I see. You want to get the shared data installed twice although it
> does not depend on the Python version (and the plattform). But thats
> not what shared data are for. While, ok, you can do it that way,
> another idea would be to make a python-pyx-common package for the
> share data (and a python-pyx-doc for the documentation) and some
> python2.x-pyx packages for the Python scripts. Ok, its a bit overkill,
> but the debian packages do it that way.

You are right, I could create two splitoff for the package one for the 
docs and one for the shared datas. I'll try if it is feasible this 
week-end.

Andrea.

Re: [PyX-devel] Installing PyX to a non-standard location.

[Andre W. <wo...@us...>]

Hi Andrea,

On 17.11.04, Andrea Riciputi wrote:
> First of all I'll summarize how Fink works. Here there are the main  
> steps (AFA I understood them):
> 
> 1) fink create a new subtree: /sw/src/root-packagename
> 
> 2) and put in there the expanded tarball and compile it
> 
> 3) then it create another new subtree: /sw/src/root-packagename/sw
> 
> 4) and it installs all the files under that subtree
> 
> 5) at the end of this process you have all your files (in the case of  
> PyX) under:
> 
> /sw/src/root-pyx-wierda-py23-0.7-6/sw/lib/python2.3/site-packages/pyx- 
> py23
> 
> /sw/src/root-pyx-wierda-py23-0.7-6/sw/share/pyx-py23
> 
> /sw/src/root-pyx-wierda-py23-0.7-6/sw/etc
> 
> 5) at this point fink calls dpkg (the debian utily) that create a sort  
> of debian package.
> 
> 6) eventually dpkg installs the new package in the right location.
> 
> Given the above picture let me start with the first problem.
> 
> ** pyxrc subtree **
> 
> Without the patch line:
> 
> >--- PyX-0.7/setup.py.orig       Mon Nov 15 16:30:04 2004                
> >                                       +++ PyX-0.7/setup.py    Tue Nov  
> >16 13:24:08 2004
> >@@ -53,7 +53,7 @@
> >                              "pyx/lfs/foils30pt.lfs",                  
> >                                                                      
> >"contrib/pyx.def"]),                                                    
> >                        # /etc is taken relative to "setup.py install  
> >--root=..."                                      -               
> >("/etc", ["pyxrc"])]                                                    
> >                        +              ("@PREFIX@/etc", ["pyxrc"])]
> 
> self.root is '/sw/src/root-pyx-wierda-py23-0.7-6' and the pyxrc file is  
> written under /etc (not /sw/etc!!). As a side effect when the user try  
> to remove pyx (with fink remove pyx) dpkg recognize that the only file  
> that it has ever installed in /etc is pyxrc and so it removes /etc as  
> well!! I've been lucky enough that /etc under MacOSX is a sym-link and  
> not the effective directory!!!

Oh my goodness.

What I don't understand upto now is, why the pyxrc gets installed to
"/etc". In step 4 above everything is fine. With the siteconfig below
it should work on this installation position. Couldn't you do this by
using the distutils install command with the proper --root and
--prefix and without any patch? Then everything is fine, and you could
copy it to the final location ... only the siteconfig.py would be
needed to be adjusted (since you copy it around).

> ** siteconfig.py **
> 
> Given the way in which Fink perform the installation process  
> sitecofing.py contains the following lines:
> 
> lfsdir = '/sw/src/root-pyx-wierda-py23-0.7-6/sw/share/pyx'
> sharedir = '/sw/src/root-pyx-wierda-py23-0.7-6/sw/share/pyx'
> pyxrc = '/sw/src/root-pyx-wierda-py23-0.7-6/etc/pyxrc'
> 
> because self.install_dir is '/sw/src/root-pyx-wierda-py23-0.7-6/sw' so  
> that PyX fails. The following patch fix the problem:
> 
> >--- PyX-0.7/setup.py.orig       Mon Nov 15 16:30:04 2004
> >+++ PyX-0.7/setup.py    Tue Nov 16 13:24:08 2004
> >
> >@@ -95,8 +98,11 @@
> >
> >     def run(self):
> >         install_data.run(self)
> >-        self.pyx_lfsdir = self.pyx_sharedir =  
> >os.path.join(self.install_dir, "share", "pyx")
> >-        self.pyx_pyxrc = os.path.join(self.root or "/", "etc",  
> >"pyxrc")
> >+        self.pyx_lfsdir = self.pyx_sharedir =  
> >os.path.join("@PREFIX@", "share", "pyx-py@PYTHON_FLAVOR@")
> >+        self.pyx_pyxrc = os.path.join("@PREFIX@", "etc", "pyxrc")

Since you want to copy the finally installed version around, you're
right to patch siteconfig.py. You can do so by a patch to the setup
script, right, since you want to write some different data into that
file. Alternatively you could also create your own siteconfig.py
overwriting whatever was created by distutils and the PyX setup
script when copying PyX to its final destination.

> Evetually the @PYTHON_FLAVOR@ is mandatory because Fink still has  
> Python 2.2 and 2.3 flavours and a user may want to have both installed.

I see. You want to get the shared data installed twice although it
does not depend on the Python version (and the plattform). But thats
not what shared data are for. While, ok, you can do it that way,
another idea would be to make a python-pyx-common package for the
share data (and a python-pyx-doc for the documentation) and some
python2.x-pyx packages for the Python scripts. Ok, its a bit overkill,
but the debian packages do it that way.


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

Re: [PyX-devel] Installing PyX to a non-standard location.

[Andrea R. <ari...@pi...>]

Hi Andre,
I see your point, and I've made a lot of trials. But I wasn't able to  
get fink to install properly PyX without my patch.

AFA I can understand there are two problems here. I hope to be clear  
even if my english is not so good... :-(

First of all I'll summarize how Fink works. Here there are the main  
steps (AFA I understood them):

1) fink create a new subtree: /sw/src/root-packagename

2) and put in there the expanded tarball and compile it

3) then it create another new subtree: /sw/src/root-packagename/sw

4) and it installs all the files under that subtree

5) at the end of this process you have all your files (in the case of  
PyX) under:

/sw/src/root-pyx-wierda-py23-0.7-6/sw/lib/python2.3/site-packages/pyx- 
py23

/sw/src/root-pyx-wierda-py23-0.7-6/sw/share/pyx-py23

/sw/src/root-pyx-wierda-py23-0.7-6/sw/etc

5) at this point fink calls dpkg (the debian utily) that create a sort  
of debian package.

6) eventually dpkg installs the new package in the right location.

Given the above picture let me start with the first problem.

** pyxrc subtree **

Without the patch line:

> --- PyX-0.7/setup.py.orig       Mon Nov 15 16:30:04 2004                
>                                        +++ PyX-0.7/setup.py    Tue Nov  
> 16 13:24:08 2004
> @@ -53,7 +53,7 @@
>                               "pyx/lfs/foils30pt.lfs",                  
>                                                                       
> "contrib/pyx.def"]),                                                    
>                         # /etc is taken relative to "setup.py install  
> --root=..."                                      -               
> ("/etc", ["pyxrc"])]                                                    
>                         +              ("@PREFIX@/etc", ["pyxrc"])]

self.root is '/sw/src/root-pyx-wierda-py23-0.7-6' and the pyxrc file is  
written under /etc (not /sw/etc!!). As a side effect when the user try  
to remove pyx (with fink remove pyx) dpkg recognize that the only file  
that it has ever installed in /etc is pyxrc and so it removes /etc as  
well!! I've been lucky enough that /etc under MacOSX is a sym-link and  
not the effective directory!!!

** siteconfig.py **

Given the way in which Fink perform the installation process  
sitecofing.py contains the following lines:

lfsdir = '/sw/src/root-pyx-wierda-py23-0.7-6/sw/share/pyx'
sharedir = '/sw/src/root-pyx-wierda-py23-0.7-6/sw/share/pyx'
pyxrc = '/sw/src/root-pyx-wierda-py23-0.7-6/etc/pyxrc'

because self.install_dir is '/sw/src/root-pyx-wierda-py23-0.7-6/sw' so  
that PyX fails. The following patch fix the problem:

> --- PyX-0.7/setup.py.orig       Mon Nov 15 16:30:04 2004
> +++ PyX-0.7/setup.py    Tue Nov 16 13:24:08 2004
>
> @@ -95,8 +98,11 @@
>
>      def run(self):
>          install_data.run(self)
> -        self.pyx_lfsdir = self.pyx_sharedir =  
> os.path.join(self.install_dir, "share", "pyx")
> -        self.pyx_pyxrc = os.path.join(self.root or "/", "etc",  
> "pyxrc")
> +        self.pyx_lfsdir = self.pyx_sharedir =  
> os.path.join("@PREFIX@", "share", "pyx-py@PYTHON_FLAVOR@")
> +        self.pyx_pyxrc = os.path.join("@PREFIX@", "etc", "pyxrc")


Evetually the @PYTHON_FLAVOR@ is mandatory because Fink still has  
Python 2.2 and 2.3 flavours and a user may want to have both installed.

Any suggestion is welcome.

Cheers,
   Andrea.

Re: [PyX-devel] Installing PyX to a non-standard location.

[Andre W. <wo...@us...>]

Hi Andrea,

On 16.11.04, Andrea Riciputi wrote:
> I was working to a new Fink package for the new PyX 0.7, when realized 
> that the *.lfs files are not found by PyX because are searched in the 
> wrong place. After digging a little bit I've found a solution that I 
> think is far less than optimal. It consists of a little patch to 
> setup.py:
[snip]
> where @PREFIX@ is replaced before install phase by the Fink prefix 
> directory (usually /sw).
> 
> As far as I can remember Andre uses Fink as well, so I'm wondering if 
> he know a better way of getting PyX installed with the right paths 
> written in siteconfig.py

Right, I'm using Fink (so thanks by the way to you and the other
maintainers of the distribution, which allows me to add some of my
favourite software to my system without any hassle -- its a great
value!). But I do not install PyX systemwide myself to avoid confusion
between all the different versions I'm using ...

Back to the problem. Right. The Fink installation scheme needs some
adjustments. When I was working on the siteconfig.py this summer, I
excatly had in mind this Fink installation scheme. I searched for a
solution to modify the installation directories via distutils and it
should work (and help you to solve the issue). The idea is to modify
the installation root to place everything under /sw. While Python
distutils seems to be configured to use a prefix /sw instead (1), we
have to modify this behaviour. When I run:

    python2.3 setup.py install --root=/sw --prefix=

distutils places the files under:

    /sw/lib/python2.3/site-packages/pyx
                      (all the python files and c extension modules)
    /sw/share/pyx     (lfs-files, pyx.def)
    /sw/etc/pyxrc

The siteconfig.py becomes:

    lfsdir = '/sw/share/pyx'
    sharedir = '/sw/share/pyx'
    pyxrc = '/sw/etc/pyxrc'

and everything works well for me, as I just tried. Note that we do not
install the shared stuff to something like "pyx-py@PYTHON_FLAVOR@",
since the shared data do not depend on the python version. They might
depend on the PyX version, but actually they don't even do that
(currently).

> I've also read an old thread on PyX-devel (that I missed back on 
> April), among Andre, Joerg and Fernando Perez about this topic, but it 
> wasn't of much help, perhaps I've missed the point...

(This discussion was the starting point when I created the
siteconfig.py to keep some installation related path information. We
have to store it somewhere, as I learned from Fernando.)


André


(1) The problem with the prefix is, that it does not modifiy the
    position of the files placed on an absolute path in the
    setup-script. This affects /etc/pyxrc, which we also want to put
    into /sw/etc/pyxrc. I do not understand, why the disutils default,
    i.e. the configuration during installation of Python itself, is
    not configured that way. The reason might be, that it just makes
    no difference for python, since it does not install anything to
    "/etc" or similar. But we want to place something in /etc and we
    can do so by absolute path names only and for that the difference
    between root and prefix becomes visible.

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/