[wxPython-dev] Call for help from component devs! :-) (was Re: [wxPython-dev] 2.8.0 plans)

[Kevin Ollivier]

Hi David,

On Dec 8, 2006, at 10:21 AM, David Pratt wrote:

> Hi Kevin and Robin. I am seeing quite a bit going on with packaging  
> these days, particularly with generic buildouts that extend  
> distutils (egg packaging) for virtually anything that one may need.  
> This is done by creating recipe's that are used to the necessary  
> parts to create self contained development or deployment environments.
>
> This can take care of compiling and building from sources also  
> (while managing and tracking dependencies). A key advantage is that  
> this parts with the notion that everything must be maintained in a  
> system wide site-packages also. I find myself that site-packages  
> gets a bit polluted after a while. The requirements for all python  
> apps are not the same - as varied as the reasons one might wish to  
> run one distribution of python (or wxpython) over another.
>
> I'd like to know where wxpython fits into this reality and future.  
> While py2app, py2exe will continue to fit into desktop deployment,  
> I can see buildouts assisting with this also. For the modern python  
> developer, eggs are state of the art. Could contributed packages  
> not fit into a namespace for wxpython - and be distributed through  
> pypi on the cheeseshop?

I'm not sure what you're asking here? Your proposal sounds rather  
close to what I'm shooting for with wxaddons, but the fact that  
you're asking if this is possible makes me think you want something  
else instead... Do you mean to simply ask if we're going to adopt  
setuptools/PyPI for all this?

> Could not even wxpython itself be refactored into a series of eggs  
> (that may be reconstituted to sort out dependencies) and  
> distributed though the same mechanism.

IIUC, there were issues with creating an 'egg' of wxPython because it  
needs to install shared dependencies outside of the Python tree (i.e.  
system-wide shared libs), and setuptools wasn't really designed to do  
that. Whether or not that is still the case, I don't know.

I think the real answer to your questions though is that someone's  
going to have to take the time out to determine the feasibility of,  
and then implement, the things you mentioned, and at least I am  
stretched for time as it is. It is not hard to come up with ways to  
improve wxPython; what seems to be difficult is getting people who  
are interested in helping to turn those ideas into reality.

Regards,

Kevin

> Python is python after all, and we are only talking about packages  
> that can fit into one or more generic namespaces. It is only  
> important that apps are aware of the namespace to accept imports.  
> Many thanks.
>
> Regard,
> David
>
>
> Kevin Ollivier wrote:
>> Hi Robin and all,
>> On Nov 30, 2006, at 12:31 PM, Robin Dunn wrote:
>>> Hi folks,
>>>
>>> I just wanted to give all of you a heads up that wxWidgets and  
>>> wxPython 2.8.0 will be released sometime around next weekend in  
>>> order to meet the new cut-off date for getting the release into  
>>> Apple's hands for OSX 10.5.  So if any of you are planning on  
>>> updates to your contributed modules, or want to get new modules  
>>> contributed, now is the time to do it.  I would like to have  
>>> everything ready to go by 1 week from tomorrow.
>> Speaking of which, would anyone be interested in helping me test  
>> out the wxAddons system I've been working on? It's a system for  
>> allowing contributed modules to be dynamically upgradable, and for  
>> non-contributed modules to be easily found/installed/managed.  
>> Think of a CPAN or CheeseShop for wxPython components. The  
>> wxaddons module is included in the wxPython preview release Robin  
>> released on Thursday, and the guts of it are ready to go. (I'm  
>> still working on the web site, though.) Here's a quick FAQ:
>> 1) Why not just have the component installed into wx.lib?
>> Because things in wx.lib are only updated when wxPython is, and if  
>> there's a significant bug, wxPython users are stuck with it. The  
>> only alternatives are to hack an install routine to update wx.lib  
>> modules, or require a separate import syntax  Things in wxaddons  
>> are dynamically upgradable - even the components actually  
>> distributed with wxPython.
>> 2) How does the user install my component?
>> For right now, the easiest way is to do "import wxaddons; import  
>> wxaddons.myModule". Unless the user has turned off component  
>> checking, when wxaddons realizes the module doesn't exist, it will  
>> try querying the wxaddons database for the component, and if it  
>> exists, it will prompt the user to download the component. In  
>> other words, automated dependency installation. ;-)
>> They can also download the source tarball themselves at any time,  
>> then unpack it and do python setup.py install, just like any other  
>> distutils module - only this module will go into the wxaddons  
>> module instead of plain site-packages.
>> In the future, there will be a GUI for managing components, but  
>> obviously the focus for 2.8 was getting the guts in good shape so  
>> that Leopard users could use this system and would just have to  
>> download the GUI later.
>> 3) What if I've got a wxaddon distributed with wxPython, but my  
>> app needs a newer version than what's installed?
>> In this case, do "install wxaddons; wxaddons.require_addon_version 
>> (name="myModule", version="1.0.0", canBeNewer=True) # or false ;-)
>> This will use the same automated dependency installation logic, so  
>> if the user doesn't have the version it will help them get it.
>> 4) So how do I get started?
>> Read this http://wxaddons.wxcommunity.com/wxaddon_guide.html. That  
>> has all the info, and all the links, you need to create your own  
>> component.
>> 5) Is the web site really going to look plain like that?
>> I'm working on a design here, but I haven't worked out the system  
>> for updating pages when the template is updated:
>> http://wxaddons.wxcommunity.com/index_draft.html
>> I might just go the typical PHP route and have header() and footer 
>> () functions, as I need to be able to add various PHP bits  
>> throughout the page, but I'm still looking at a way I can cleanly  
>> separate the template into a plain HTML page. (Was that  
>> explanation too long? ;-)
>> Thanks,
>> Kevin
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: wxPython-dev-unsubscribe at lists.wxwidgets.org
>> For additional commands, e-mail: wxPython-dev- 
>> help at lists.wxwidgets.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wxPython-dev-unsubscribe at lists.wxwidgets.org
> For additional commands, e-mail: wxPython-dev-help at lists.wxwidgets.org
>