packaged Pylons, ready to use
by Kyle VanderBeek
(Sorry for the repost, didn't want this to get lost in a thread about
naming conventions.)
For those of you insterested in playing with Pylons, I've hacked out
spec files and built RPMs for F8:
http://www.kylev.com/pylons-rpm/
I haven't done anything other than make sure that everything installs
and paster can do "create" and "serve", so consider this early access.
I believe all the other prereqs (like python-simplejson and python-nose)
are available via yum. Feedback welcome! If these test out ok for you
all, I may submit them for F9.
--
kylev(a)kylev.com
Some people have a way with words, while others... erm... thingy.
16 years
pychecker stories/feedback?
by James Laska
Greetings!
I've been playing around with a side project of using pychecker to
provide early warning of typos/thinkos and questionable practices. I'm
basically looking for many of the benefits that a compiler provides when
it can't resolve find a variable/class/function name etc...
I've got the right mix of pychecker cmdline args such that the subset of
issues is now manageable. But I'm curious if folks have any general
thoughts on this subject.
What are your best practices?
Are there other similar tools out there?
Have any experiences to share or words of caution/wisdom?
Many thanks,
James
--
==========================================
James Laska -- jlaska(a)redhat.com
Quality Engineering -- Red Hat, Inc.
==========================================
16 years
Python package naming guidelines
by Timothy Selivanow
I feel this is more nit-picking, but I'm currently working on packaging
the following items (python/zope names) and need some direction:
zc.buildout
zope.proxy
ZConfig
zdaemon
zope.testing
ZODB3
I haven't exactly liked the current naming conventions, as they leave
way too much variation while still being "acceptable". E.g., a package
I have already done, pysvn, could have been named "python-pysvn" or
"pysvn". If it had been used as "import svn", I would have no problems
calling it "python-svn", as that would denote that it is a python
package having something to do with SVN (since SVN is already a
well-known entity), but upstream calls itself "pysvn" while also using
that as the python package name, so calling it "python-pysvn" seemed
redundant. However, with the above, there seems to be more ambiguity.
Adding to my naming troubles, there is already a package for
zope.interface, which is a dependency of ZODB3, and it's name is
python-zope-interface. The problem I am having is that it seems to me
that if an entity is fairly standalone, i.e. there is no ambiguity
whether or not it is a python (or any other language)
library/application, that the "python" prefix would be dropped. We
don't currently call TurboGears, "python-TurboGears" (yet there are
other turbo-related libs that follow the python prefix scheme, e.g.
python-turbokid and python-turbocheeta).
Really, I'm asking the Python consuming portion of the Fedora Community
what they would rather see. I can also take this up on the packaging
list, but thought I'd ask here first because potentially it's the people
on this list that would be consuming these packages.
Would it be:
python-zc-buildout
python-zope-proxy
python-ZConfig
python-zdaemon
python-zope-testing
python-ZODB3
python-zope (thrown in to add contrast, and I'm still working on
packaging it...)
Or the above without the prefix?
It seems to me that there should be a more firm guideline that takes
into account python applications, python only frameworks/libs, and
python lib ports (these seem to be the bulk of how a name would be
determined).
--Tim
_______________________________________________________________________
/ Much of the excitement we get out of our work is that we don't really \
| know what we are doing. |
\ -- E. Dijkstra /
-----------------------------------------------------------------------
\
\ \
\ /\
( )
.( o ).
16 years, 1 month
help with simple script and strings
by John Poelstra
I'm just getting started with python. Curious what I need to change to
properly filter out only strings starting with "200"
script:
#!/usr/bin/python
directories = ['20080412', '20080324', 'blahblah', 'latest-dir',
'rawhide-20080410', 'rawhide-20080411', 'rawhide-20080412' , '20080401']
print 'directories == %s' % directories
for directory in directories:
print 'processing directory %s ' % directory
if not directory.startswith('200'):
directories.remove(directory)
print 'removed == %s' % directory
print 'directories == %s' % directories
~~~~~~~~~~~~~~~~~~~~~~~~~
output:
$ python dir-filter.py
directories == ['20080412', '20080324', 'blahblah', 'latest-dir',
'rawhide-20080410', 'rawhide-20080411', 'rawhide-20080412', '20080401']
processing directory 20080412
type == <type 'str'>
processing directory 20080324
type == <type 'str'>
processing directory blahblah
type == <type 'str'>
removed == blahblah
processing directory rawhide-20080410
type == <type 'str'>
removed == rawhide-20080410
processing directory rawhide-20080412
type == <type 'str'>
removed == rawhide-20080412
directories == ['20080412', '20080324', 'latest-dir',
'rawhide-20080411', '20080401']
~~~~~~~~~~~~~~~~~~~~
why do 'rawhide-20080411' and 'latest-dir' remain?
Thanks,
John
16 years, 1 month
Pakaging enthought tool suite
by Gael Varoquaux
Hi,
I am the guy who asked about packaging mayavi2 a few weeks ago.
Unfortunately I didn't realize the discussion was going on on the ML with
me following.
To pick up on the points that have been raised on the ML:
I agree that packaging the whole Enthought Tool Suite would be very nice,
and much better than shipping it in a coarse-grained set of packages, as
Debian and Ubuntu have been doing. Making 15 or so packages is more work
than making 4, but it is more value.
I, and probably Dave Perterson and many other on the enthought-dev
mailing list (https://mail.enthought.com/mailman/listinfo/enthought-dev )
would be very happy to help you in this endeavour by answering any
question you have about the ETS. I do not have any experience with RPM
packaging, and do not have access to a fedora box to test, but I can try
to help with as much as I can by providing upstream knowledge and fixing
small problems upstream, if any.
I am now subscribed to this mailing list (god, another mailing list in my
already cramed mailbox, how will I ever get some work done!). Keep me
posted. I want to stress that if you don't have the time to package all
the ETS with all the different packages, a set of 4 packages is what we
settled for Debian to distribute the whole suite. Better this than no
packages, and the modularity can come later.
Keep me posted.
Cheers,
Gaël
16 years, 1 month
naming conventions (and an intro)
by Kyle VanderBeek
I couldn't find a naming convention set in the wiki, so I'll ask here.
As I prep the bits and pieces for packaged pylons on Fedora, I'm seeing
a lot of varied package names and project names. Projects like Pylons
and Mako refer to themselves with caps, but provide PEP-8 friendly
lowercase package names, and I'm wondering how we should map these to
package names.
Personally I'd rather not see a package named "Mako" since it is
meaningless outside the context of python and provides nothing in
/usr/bin. I'd probably name the package python-mako to make it sort
near python-*, which seems to be fairly common in Fedora and RedHat.
Does that sound right to you all?
By the way, I'm Kyle VanderBeek, professional software developer for
IronPort (a Cisco Company). I've been doing software development for
more than a decade now, as well as administering a variety of Unix
systems including RedHat/RPM Linux distros going back to 4.0 (no, not
RHEL 4; actual RedHat Linux 4.0). I currently do the majority of my
work in Python, writing massive email anti-spam and reputation systems
to protect your mom's Inbox.
--
kylev(a)kylev.com
Some people have a way with words, while others... erm... thingy.
16 years, 1 month
[Fedora-python-devel-list] [Fwd: Python SIG mailing list/packaging mayavi2]
by Ignacio Vazquez-Abrams
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>
To: ivazqueznet+wiki(a)gmail.com
Subject: Python SIG mailing list/packaging mayavi2
Date: Thu, 20 Mar 2008 08:01:29 +0100
Hi,
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
are:
python-enthought-traits
python-enthought-traits-ui
mayavi2
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
the process.
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.
Cheers,
Gaël
--
Ignacio Vazquez-Abrams <ivazqueznet(a)gmail.com>
16 years, 1 month
New to mailing list
by Brad Malone
Hi all, I just joined the mailing list. So I guess I'll say a little about
myself.
I'm a physics graduate student who does a significant amount of scientific
programming in python (including numpy/scipy). I've also done some other
things in Python as well outside of scientific programming, specifically
making a couple of GUIs (tools to make my fiancee's linux experience easier)
and internet related tools (simply scripts that monitor the online prices of
things I'd like to buy and alert me when the price drops low enough). I
still have a lot to learn about Python, but I've been introduced to a number
of things that I wouldn't come across usually doing physics. So I'd say I
have a decent idea of the scope of what Python can do, although perhaps in
some cases not enough experience to do certain things without consulting
references.
I've been wanting to figure out a way as to how I could help contribute to
the Fedora project. I don't know what exactly you do in the Python SIG, but
I thought I'd hang around and find out.
Best,
Brad
16 years, 1 month
Introduction
by Jason Fenner
Yet another introduction...
I am an experienced SysAdmin and have done quite a bit of scripting in Perl
and BASH.
However, for about the last year or two my hands down favorite language to
continue to learn and use is Python.
I am not a Python expert by far but feel quite confident using it to solve
problems wherever they might arise.
Currently, I am desiring to learn Django and TurboGears so that I can
develop some web sites that I've had ideas on.
I look forward to what might develop on this list and help out however I
can.
--
=+=+=+=+=+=+=+=+=+=+=+=
Jason
aka, Axelilly
Catch me on gchat or Jabber
=+=+=+=+=+=+=+=+=+=+=+=
16 years, 1 month
