python-devel May 2013

python-devel@lists.fedoraproject.org

8 participants
5 discussions

Feedback request: next generation of upstream Python metadata

by Nick Coghlan

Hi all, The initial draft of Python's next generation metadata standard is up on python.org: PEP 426 (metadata 2.0): http://www.python.org/dev/peps/pep-0426/ PEP 440 (versioning): http://www.python.org/dev/peps/pep-0440/ The rationale for many of the changes is at the end of each PEP, along with some comments on features that I have either rejected or deliberately chosen to defer to the next revision of the metadata (at the earliest). Those with BitBucket accounts may also comment inline on the drafts here: PEP 426: https://bitbucket.org/ncoghlan/misc/src/05d3586464b10d6a04a35409468269d7c... PEP 440: https://bitbucket.org/ncoghlan/misc/src/05d3586464b10d6a04a35409468269d7c... The distutils-sig thread is here: http://mail.python.org/pipermail/distutils-sig/2013-May/020863.html Possible changes already being discussed: * Contact metadata: "type" -> "role" "individual" -> "contributor" Lose the "organization" type (allows orgs to be entered for any role) * New top level field "distributes" Like "requires", but doesn't discourage version pinning Used for metapackages (like PyObjC) May map nicely to software collections Cheers, Nick. -- Nick Coghlan Red Hat Infrastructure Engineering & Development, Brisbane Test Automation Team Lead Beaker Development Lead (http://beaker-project.org/) PulpDist Development Lead (http://pulpdist.readthedocs.org)

10 years, 12 months

2
2
0 / 0

Who's going to flock?

by Toshio Kuratomi

(For those who are subscribed to this list as well, forgive me for CC'ing -- I hadn't recalled seeing you post here, so I wasn't sure if you were on the list too). Hey, who's going to flock[1]_? I'm thinking of adding a hackfest for discussing a new version of the Python Guidelines if we have the right people. I've got the following list of things that could be discussed if the right people are there: * New methods of building packages (wheels) [ncoghlan, toshio, bkabrda] - What are the steps to building with wheels - What new packages are needed - To macroize or not to macroize * python3 - Long standing bug about the use of py3dir [thm, dmalcolm, toshio] https://bugzilla.redhat.com/show_bug.cgi?id=563622 - Naming of python modules [tomspur, mrunge?, toshio] - More fluid definition of "python" (ie, it could be python3) [tomspur] - Switching to it as "default" (what that means and what we can/should do to move it forward) + python-modernize, six, other packages that will help + What packages block doing that + Perhaps this could be similar to the Ubuntu definition: the livecd and programs on it should use the python3 runtime. * alternate interpreters (pypy seems to be the most compatible and therefore the one we might be most interested in but jython is also in fedora) [tomspur, toshio, bkabrda, pypy: (dmalcolm, mstuchli), jython: (akurtakov, tradej)] - Do we want to share modules between interpreters? The cpython2 and pypy interpreters support nearly the same things. The ruby interpreter precedent is to share the modules. But we do have compiled bytecode in python whereas ruby does not. So we'd share .py files but still need separate .pyc files. On the pre-registration list I currently see: mrunge, ncoghlan, toshio. This seems tantalyzingly close to enough people to work on at least one of the areas above. Anyone else coming? Anyone else have things they want discussed (and will you be there to kick off the conversation?) .. [1]_: http://flocktofedora.org/ -Toshio

10 years, 12 months

3
4
0 / 0

Discussion: Macros for Python Specfiles

by Bohuslav Kabrda

Hi all, as mentioned in [1], I'd like to start a discussion about proposed Python macros. The full macro file can be seen at [2] and an example diff of converted spec at [3]. The important macros from the proposal are: %py_default_filter # will filter all *.so file provides from /usr/lib{64}/pythonX.Y/site-packages %py[3]_build # will run setup.py build with proper args/flags %py[3]_install # will run setup.py install with proper args I already proposed this to fpc [4], but it seems that there is a disagreement [5] about the %py_{build,install} macros. This is why I'd like to start a broader discussion about them here. Thank you for your opinions. Slavek. -- Regards, Bohuslav "Slavek" Kabrda. [1] https://bugzilla.redhat.com/show_bug.cgi?id=953704 [2] https://bugzilla.redhat.com/attachment.cgi?id=739290 [3] https://bugzilla.redhat.com/attachment.cgi?id=739291 [4] https://fedorahosted.org/fpc/ticket/281 [5] https://bugzilla.redhat.com/show_bug.cgi?id=953704#c10

11 years

3
3
0 / 0

(no subject)

by Francisco Javier Hernandez Santiago

-- Saludos! Javier Hernández Santiago Ing. Electrónica y Comunicaciones Universidad de Guadalajara Cel. 3313 6018 75

11 years

1
0
0 / 0

Reassigning most of my packages to "python-maint@redhat.com"

by David Malcolm

For the last 3 years I've been paid by Red Hat to work on Python runtimes within Fedora (and RHEL). I'm still going to be around, but I'm going to be focusing on the gcc work I've been doing. Bohuslav "Slavek" Kabrda (bkabrda(a)redhat.com) will be spending more of his time on Python, and I believe RH is also planning to assign some more people to Python. Hence RH has created a "python-maint(a)redhat.com" address to be "the team within Red Hat who work on Python", which currently is myself and Slavek, and probably some more RH employees. (I believe we have a similar thing in place for the kernel). Currently I'm marked as owner of 24 packages in Fedora (and EPEL), but I've been fairly free in handing out commit rights to people who want them: RunSnakeRun -- GUI Viewer for Python profiling runs gcc-python-plugin -- Plugins for embedding various versions of Python within GCC gdb-heap -- Extensions to gdb for debugging dynamic memory allocation perl-Class-CSV -- Class based CSV parser/writer pypy -- Python implementation with a Just-In-Time compiler python -- An interpreted, interactive, object-oriented programming language python-docs -- Documentation for the Python programming language. python-meliae -- Python memory usage statistics python-numarray -- Python array manipulation and computational library python-pefile -- Python module for working with Portable Executable files python-rdflib -- Python library for working with RDF python-six -- Python 2 and 3 compatibility utilities python-sqlparse -- Non-validating SQL parser for Python python-squaremap -- SquareMap for wxPython python-subprocess32 -- Backport of subprocess module from Python 3.2 to Python 2 python-testosterone -- Text-based UI for running Python unit tests python-xmltramp -- Pythonic API for XML python26 -- Parallel-installable Python 2.6 for EPEL5 python26-distribute -- the "Distribute" fork of setuptools for the python26 EPEL package python26-nose -- The "nose" testing package for the python26 EPEL package python3 -- Version 3 of the Python programming language aka Python 3000 python3-cherrypy -- Pythonic, object-oriented web development framework python3-postgresql -- Connect to PostgreSQL with Python 3 squeal -- Data manipulation tool for the command line I'd like to reassign "owner" on almost all of these from "dmalcolm" to the python-maint address, the exceptions being 3 that are particularly close to my heart: * gcc-python-plugin * gdb-heap * squeal Anyone have a burning desire to take over any of the others? [I guess we can live with the irony of having "perl-Class-CSV" be owned by "python-maint(a)redhat.com" :) ] I believe Slavek is currently working on updating the Fedora packages to the recently released 2.7.4 (and then 3.3.1 and 3.2.4 - though I'm sure he'd appreciate help, but tell him first if you want to work on these, so we don't duplicate work!) Hope this sounds sane Dave

11 years

5
12
0 / 0

← Newer
1
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-devel May 2013