Restructuring Python ports?

[Randall Wood]

I would like to suggest the following:

That for each version of python (pythonxy), there be the following  
ports:

pythonxy, which installs nothing (maybe a readme file so that macports  
can consider it installed), but which depends on the following:

pythonxy-core, which is analogous to the current python24 and python25  
ports,

pyxy-whatever, which, when all pyxy-whatever ports are installed,  
provide a complete basic python installation of the core modules. (I'm  
not suggesting that every pyxy-* port be installed, only those which  
are required to provide the disabled modules)

We may also want to provide a pythonxy-x11 or pythonxy-core-gui port  
which would include the basic python tk/x11 gui capabilities so that  
pythonxy-core does not include an X11 dependency.

This may provide an advantage over throwing everything into a single  
port in that it would allow the pyxy-whatever ports to be updated  
independently of the pythonxy-core port if they need to be.

On 2 Jan 2009, at 05:17, Akira Kitada wrote:

> I prefer the way how python26 is built now to python25's, mostly
> because it eliminated the need to specify
> "depends_lib-append port:py25-hashlib port:py25-zlib" again and  
> again...
>
> I'm so happy with it and really hate the way it was in python25,
> and that's why I wanted it to be propagated to other versions of  
> python,
> even it breaks the existing ports. (To me they are already broken in
> different way)
>
> I think it's safe to drop "bsddb", "sqlite3", "tkinter" and  "gdbm",
> just as in FreeBSD Port system, though.
>
> On Fri, Jan 2, 2009 at 4:48 PM, Marcus Calhoun-Lopez
> <mcalhoun at macports.org> wrote:
>> Akira Kitada <akitada at ...> writes:
>>
>>> So it's going to remain the same: all-in-one python26 port and other
>>> sliced python ports.
>>> No intentional breakages are introduced.
>>
>> For what it's worth, I was a proponent of getting rid of
>> disabled_module_list in python26 (http://trac.macports.org/changeset/42841 
>> ).
>> Most importantly, disabled_module_list precludes an exact  
>> replication of
>> a full install (http://trac.macports.org/ticket/12369).
>> It also makes maintenance easier.
>>
>> Having python ports be "dependency heavy" does not strike me as
>> overly burdensome.
>> Python does a lot of useful things, and it seems right and good that
>> it require many dependencies to help it achieve its goals.
>>
>>> Bryan declined this by saying "for 3.0 i'll definitely contact mww;
>>> but for 2.4/2.5 i'm not sure of the breakage that will happen".
>>
>> A few days ago, I proposed getting rid of disabled_module_list in  
>> python30
>> (http://trac.macports.org/ticket/17796).
>>
>> -Marcus
>>
>> _______________________________________________
>> macports-dev mailing list
>> macports-dev at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev