Bug 24231

On Wed 2001-01-10 (14:10), ak03@gte.com wrote:
> 	pyexpat.so is a Python interface to the well known expat
> 	parser. Attached patch adds required dependencies to the
> 	pythoin port in order to allow the pyexpat extension module
> 	to build successfully. 

Doesn't the textproc/py-xml port provide this functionality?

Neil
-- 
Neil Blakey-Milner
nbm@mithrandr.moria.org

py-xml is a port for the XML processing stuf from Python XML SIG. The package
is installed as _xmlplus if built under Python 2.0 and consequently will work
only with code which is aware of this fact (none does, AFAIK). The Python 2.0
built-in XML modules do not provide as many features as SIG code does, but I
see no reason why they shouldn't  be built by default.

On 10-Jan-2001 Neil Blakey-Milner wrote:
> On Wed 2001-01-10 (14:10), ak03@gte.com wrote:
>>      pyexpat.so is a Python interface to the well known expat
>>      parser. Attached patch adds required dependencies to the
>>      pythoin port in order to allow the pyexpat extension module
>>      to build successfully. 
> 
> Doesn't the textproc/py-xml port provide this functionality?
> 
> Neil
> -- 
> Neil Blakey-Milner
> nbm@mithrandr.moria.org

----------------------------------
E-Mail: Alexander N. Kabaev <ak03@gte.com>
Date: 10-Jan-2001
Time: 15:36:18
----------------------------------

ak03@gte.com writes:

> Index: Makefile
> ===================================================================
> RCS file: /home/ncvs/ports/lang/python/Makefile,v

I won't accept that. Please create a separate py-expat port, similar
to py-tkinter or py-gdbm.

tg

It is a part of standard Python 2.0 distribution and it does not make sence to
artificially separate pyexpat from the rest of the distribution.

Why didn't you separate gmp and OpenSSL parts using the same logic?
On 11-Jan-2001 Thomas Gellekum wrote:
> ak03@gte.com writes:
> 
>> Index: Makefile
>> ===================================================================
>> RCS file: /home/ncvs/ports/lang/python/Makefile,v
> 
> I won't accept that. Please create a separate py-expat port, similar
> to py-tkinter or py-gdbm.
> 
> tg

----------------------------------
E-Mail: Alexander N. Kabaev <kabaev@mail.ru>
Date: 11-Jan-2001
Time: 08:51:10
----------------------------------

"Alexander N. Kabaev" <kabaev@mail.ru> writes:

> Why didn't you separate gmp and OpenSSL parts using the same logic?

The necessary gmp and SSL sources are part of the base system and the
support can be compiled in without any {WANT,WITHOUT}_* options and
without external dependencies.

It's easy enough to create another port for more granularity and I
prefer that way over make options. We have too many of those already.

tg

Neil Blakey-Milner on 2001-01-10 (Wed) at 12:40:02 -0800:
> 
>  On Wed 2001-01-10 (14:10), ak03@gte.com wrote:
>  > 	pyexpat.so is a Python interface to the well known expat
>  > 	parser. Attached patch adds required dependencies to the
>  > 	pythoin port in order to allow the pyexpat extension module
>  > 	to build successfully. 
>  
>  Doesn't the textproc/py-xml port provide this functionality?

Yes, it does.

-- Johann

Allow me to clarify that my previous statement:

PyXML contains the pyexpat.so source in its distribution tarball.  I believe
that it is currently stock pyexpat (but I speak under correction).

At present, PyXML's installation procedure...
- checks for a pre-existing pyexpat, and if there is one
- checks to see if its version is recent enough.

If it is satisfied that a sufficiently recent pyexpat is already installed,
it does install its own pyexpat.  This would of course play hell with the
py-xml port's ${PLIST}, but it is probably something that can be overcome if
a pyexpat port that meets tg's approval is submitted.

However, it seems likely that in future versions PyXML will ship with a
modified pyexpat, and will force the installation of its custom version.
Sigh.

[ Moving O/T ]

These module interdependencies are going to get worse, not better.  PyXML and
Fourthought's 4Suite have always been kissing cousins.  A port of 4Suite is
desperately needed IMO.  (Peter Haight has submitted a 4Suite port three
times but the PRs are still open.  The latest is ports/23903.)  The current
PyXML 1.6.3 does "not cooperate" with 4Suite.  4Suite's authors have "had
enough" of this, and as of 4Suite 0.10.1, PyXML will be bundled with it.
Sigh again.

Because of the close links between the core Python distribution and PyXML,
and the fact that py-xml port dependencies are handled by bsd.python.mk,
*and* the fact that PyXML is still so volatile, the whole pyexpat / PyXML /
4Suite business should probably be handled with care.  I'll hopefully be able
to come up with something once 4Suite 0.10.1 actually gets released.

-- Johann

Thomas Gellekum on 2001-01-12 (Fri) at 15:00:53 +0100:
> 
> > If it is satisfied that a sufficiently recent pyexpat is already installed,
> > it does install its own pyexpat.  This would of course play hell with the
>      ^^^^
> ITYM "doesn't"?

Sorry, yes.  That's what I meant.  :-)

> Actually, I don't care where the source for pyexpat.so comes from. I
> just don't want more options in the base python port. A
> textproc/py-expat doesn't need my approval.

Fair enough!

-- Johann

Johann Visagie <johann@egenetics.com> writes:

> PyXML contains the pyexpat.so source in its distribution tarball.  I believe
> that it is currently stock pyexpat (but I speak under correction).
> 
> At present, PyXML's installation procedure...
> - checks for a pre-existing pyexpat, and if there is one
> - checks to see if its version is recent enough.
> 
> If it is satisfied that a sufficiently recent pyexpat is already installed,
> it does install its own pyexpat.  This would of course play hell with the
     ^^^^
ITYM "doesn't"?

> py-xml port's ${PLIST}, but it is probably something that can be overcome if
> a pyexpat port that meets tg's approval is submitted.

Actually, I don't care where the source for pyexpat.so comes from. I
just don't want more options in the base python port. A
textproc/py-expat doesn't need my approval.

tg

On 12-Jan-2001 Thomas Gellekum wrote:
> Johann Visagie <johann@egenetics.com> writes:
> 
>> PyXML contains the pyexpat.so source in its distribution tarball.  I believe
>> that it is currently stock pyexpat (but I speak under correction).
>> 
>> At present, PyXML's installation procedure...
>> - checks for a pre-existing pyexpat, and if there is one
>> - checks to see if its version is recent enough.
>> 
>> If it is satisfied that a sufficiently recent pyexpat is already installed,
>> it does install its own pyexpat.  This would of course play hell with the
>      ^^^^
> ITYM "doesn't"?
> 
>> py-xml port's ${PLIST}, but it is probably something that can be overcome if
>> a pyexpat port that meets tg's approval is submitted.
> 
> Actually, I don't care where the source for pyexpat.so comes from. I
> just don't want more options in the base python port. A
> textproc/py-expat doesn't need my approval.

I always thought that having standard low-level interface that could be shared
among PyXML, 4DOM etc was the reason why pyexpat has been included into the
base Python 2.0 distribution. If that assumption is wrong and 4DOM and PyXML
will be rolling their own possibly incompatible versions anyway, then I have to
request my PR be closed. It does not make any sense to have py-expat as a
separate port outside the base python distribution either.
 
------------------------------------------
E-Mail: Alexander N. Kabaev <ak03@gte.com>
Date: 12-Jan-2001
Time: 09:28:38
------------------------------------------

Alexander N. Kabaev on 2001-01-12 (Fri) at 10:03:15 -0500:
> 
> I always thought that having standard low-level interface that could be shared
> among PyXML, 4DOM etc was the reason why pyexpat has been included into the
> base Python 2.0 distribution.

I'm searching the XML-SIG archives to see whether there is concrete thinking
behind the status of expat.  If there is, I don't remember it (but I may have
missed it).  Currently I think this is just one more example of the volatile
and unfortunate mess surrounding Python's XML handling.  Decisions seem to
get taken on an ad hoc basis and reversed often.  :-(

> If that assumption is wrong and 4DOM and PyXML
> will be rolling their own possibly incompatible versions anyway, then I have to
> request my PR be closed. It does not make any sense to have py-expat as a
> separate port outside the base python distribution either.

Since Thomas doesn't want it in the Python port, the question is currently
moot.

Still looking into this.  More later.

-- Johann

Comment 12 Steve Price 2001-02-26 02:24:00 UTC

Responsible Changed
From-To: freebsd-ports->tg

Over to port's maintainer.

Comment 13 Thomas Gellekum 2001-03-01 12:33:14 UTC

State Changed
From-To: open->closed

I have added py-expat as a port in the textproc category.