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

[David Pratt]

Hi Kevin. Thank you for your reply. I have been taken up by some of this 
newer development and wondering whether others are seeing the 
interesting potential. I have been experimenting with it and have begun 
to modify my own ideas of how I develop and deploy code. Just wondering 
whether there have had been any thoughts on eggs (and buildouts) or 
their future in wxpython. Many thanks.

Regards,
David

Kevin Ollivier wrote:
> 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
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wxPython-dev-unsubscribe at lists.wxwidgets.org
> For additional commands, e-mail: wxPython-dev-help at lists.wxwidgets.org
>