Now that most of us are here, let's get started.
I received this email from someone wanting to get mayavi2 included in
Fedora. It certainly looks like an interesting piece of software. Anyone
want to try their hand at it?
-------- Forwarded Message --------
From: Gael Varoquaux <gael.varoquaux(a)normalesup.org>
Subject: Python SIG mailing list/packaging mayavi2
Date: Thu, 20 Mar 2008 08:01:29 +0100
I would like to send an e-mail to the Fedora python SIG, but I seem to be
too stupid to find the e-mail address, so I am sending it to you. Do you
mind forwarding it to the right mailing list, with me in CC.
Here is the catch, I would like mayavi2 (
https://svn.enthought.com/enthought/wiki/MayaVi , the web page is
horendous) to be included in Fedora. I propose to do it the same way we
did it under debian, with three packages, breaking up the fonctionality
of the tools suite that we are using for better reuse. In Debian, these
I must admit that due to a large modularity of the tools suite (more like
20 packages than 3, and not all used in mayavi2), and heavy use of setuptools
packaging this stuff is not trivial. But we finally got it right with the
Debian packages, and I am sure we can talk to the maintainers and find
out what ended up being the best way to do it.
The relevent mailing-list is
https://mail.enthought.com/mailman/listinfo/enthought-dev and we will be
happy helping you doing these packages. None of the mayavi2 developpers
run an rpm-based distribution, so it is a bit hard for us to bootstrap
In terms of functionnality for the users, the webpage is terribly poorly
written, but you can find some remarks on my blog
http://gael-varoquaux.info/blog/ . I have recently had the pleasure to
see new users pick up the API and apply it to their domain-specific
problem with a lot of ease to build 3D visualization to fit their need
with small scripts. I think that for the Python scientific user, this
program answers a real need.
Ignacio Vazquez-Abrams <ivazqueznet(a)gmail.com>
On Fri, Mar 28, 2008 at 05:32:19PM -0400, Ignacio Vazquez-Abrams wrote:
> Now that most of us are here, let's get started.
> I received this email from someone wanting to get mayavi2 included in
> Fedora. It certainly looks like an interesting piece of software. Anyone
> want to try their hand at it?
I must stress that the website is a horrible mess (I am working on it
right now, but there is a fair amount of work). The installation
procedure may not seem clear, but please send e mail either to the
mailing list ( https://mail.enthought.com/mailman/listinfo/enthought-dev
) or directly to me if you want any clarification.
As far of the packaging, mayavi2 is just the top of the iceberg of a set
of tools to develop scientific applications using Python (the ETS). This
set of tools is broken in many different Python modules, but there are a
fair amount, and when packaging for Debian we decided to group the
fonctionnalities. The relevant Debian packages are
python-enthought-traits, python-enthought-traits-ui mayavi2 and
python-enthought-chaco. I don't know how easy it is for you guy to figure
out what was done for Debian packaging in order to group these packages.
I didn't do it myself, althought I bootstrapped the process, so I cannot
help you too much. One thing I did do to bootstrap the packaging, was
creating tarballs to work around the setuptools automatic downloading of
dependencies (a pain for packagers). You can find these on
http://code.enthought.com/downloads/source/ets2.7/ I try to keep them up
to date, but it is best too avoid using them, as they have been stripped
of setuptools as a runtime dependecy.
I am away for the week end (back on Sunday night). Appart from this
break, I am really looking forward to building great packages for these
tools on Fedora.
PS: Actually, there was a small glitch with e-mail, so I am sending this
after coming back from week end.
I am the founder of the Drupy project. In a nutshell, Drupy aims to
offer Drupal in Python.
(1) Offer function/class/module level compatibility with Drupal HEAD.
This allows for the following:
a) Documentation reusability
b) Portability of user-contributed Drupal modules
c) Possible endorsement from the Drupal project
d) Portability of Drupal core enhancements
e) Easy transition for current Drupal users
The policy until now has been to make whatever improvements necessary
within API functions without modifying the external interfaces to
those functions and/or classes.
(2) Improve namespace support
For the first release of Drupy, it will not be practical to completely
compartmentalize every component. However, there are certain key areas
where namespace support can be drastically improved, such as in Drupal
modules. The policy until now has been that core includes will remain
in the global namespace but all Drupal modules, both core and non core
will remain within their respective namespaces.
(3) Implement security and performance improvements where possible.
Drupal is not necesarily known for security and performance. Of course
with any application with the scope and flexibility of Drupal,
security and performnce become more difficult to maintain.
Where possible, Drupy seeks to add improvements, but only where it
will not drastically break current functionality. Great care needs to
be taken to maintain a balance.
(4) Improve theming support
Obviously, Drupy cannot completely mimic the PHPTemplate engine, but
the strengths of PHPTemplate can certainly be embraced. Embedding
application code such as PHP directly into HTML is far from preferable.
My goal for theming is to take the general principles of PHPTemplate
and apply them in the context of a good templating engine such as Mako.
Status of Project
I had spent about 5 months in the planning stages for the Drupy
project. This involved weighing out many of the difficult choices to
be made when porting Drupal. Drupal was in no way written "elegantly",
but it does its job quite well. A lot of Drupal lack of elegance comes
from the inherent lack of elegance in PHP itself.
Currently, this is what we have:
(1) A robust and well tested PHP function abstraction module for
Python. This allows us to use most Drupal function calls without any
modification. (Examples: preg_replace, isset, empty, ob_start)
(2) About 8 of the big Drupal core includes working
(3) Bootstrap Stage 3 ALMOST working
(4) Beginning stages of theming support
(5) A solid, well informed, plan of action
Although we have other developers who have just recently shown initial
interest in contributing, all of this code so far has been written by
me in the last 4 weeks.
Call to Action
I have approached this project as someone highly experienced with
Drupal, but certainly not as an expert in Python. The Drupy project
could greatly benefit from more proficient Python programmers.
Unfortunately, I have received many harsh criticisms from more
experienced Python developers for my moderate stance on the use of
global state, PHP abstraction functions, and various other details.
The truth of the matter is that Drupal is one gigantic global
namespace. Compromises will need to be made to get this project
finished. Rewriting the entire Drupal codebase for Django or
Turbogears is a 2 - 4 year project. I want to see this project running
much sooner than that.
So, with that said, I am asking for the assistance of skilled Python
developers who are willing to compromise certain (but not all)
Pythnoic practices for a short while so we can finally get Drupal in
Python. I would love to bring on other core developers who I can learn
from and who can help steer the direction of this project.
Of course, this should be an iterative process. Once a working
application is built. More elegant solutions can steadily be integrated.
Email: message144 at users ddott sourceforge dddottnet
If you want SVN access, please get in touch with me personally.
Just thought I'd toss my little introduction out there as well.
I've been a Linux/Solaris sysadmin for 8 years, and I'm a recent
convert to python from Perl.
I'm somewhere in the beginner to beginner-intermediate level for
python, however, I'll be happy to help out where ever I can.
Does anyone have a F8 spec file template for setuptools/egg-based
packages? I'd like to get an RPM ready for Pylons (and its requirement,
Mako). I've seen the wiki page:
Perhaps someone could add a "python-egg" type to rpmdev-newspec?
Some people have a way with words, while others... erm... thingy.
just a shameless plug: I submitted my first Fedora RPM and now I need a
review/a sponsor. My rpm contains the excellent pyPdf and the review
request is bug #438892 . :-)
And for the introduction part: I'm Felix Schwarz (Berlin, Germany),
self-employed software developer mostly using Python/TurboGears.
Alright, since I'm now convinced that there will be little use in having
Reply-To munging disabled for this list, I'm enabling it.
Ignacio Vazquez-Abrams <ivazqueznet(a)gmail.com>
PLEASE don't CC me; I'm already subscribed
I'm a programmer wannabe. I've used Python to write some simple scripts
for my own purposes, and a while back I worked on a PyGTK applet for
Twitter. Because I failed to make any noise about it, assuming my work
was crap, it went months without any love, and other people jumped in to
fill that void.
I'm not any better of a programmer now, but I love the language and have
to say that I understand OOP somewhat now because of it, which is
something I can't say after courses in C++.
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug