Re: Enabling salsa-ci on all Debian Python Team repos
Hi Carsten, Hi List, Le Fri, Sep 23, 2022 at 07:01:05AM +0200, Carsten Schoenert a écrit : > heavily force pushing to not blow up the git tree with dozens of Fixup > commits! In the 'official' git tree this is a no go of course. Would doing the work in a git branch and 'git merge --squash' at the end be a solution to this problem ? I have the same issue when trying to use CI to run tests instead of running them locally, but using Mercurial, I just 'hg amend' them and I end up with a clean history. With Mercurial and its concept of obsolete commit combined with the evolve extension, a team can amend commits and share these amended commits without anyone losing work. I never found the equivalent in git where rewriting an history to clean it once the dust as settled breaks every repository that already pulled these commits. In other words, Mercurial allows you to work in a decentralized fashion both on your source and on the history of your source. -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances
Re: RFS: mercurial-evolve
Hi List, Le Wed, Sep 07, 2022 at 09:12:05AM +0200, Andrej Shadura a écrit : > Thanks, you did a good job on your first Debian package :) Nice to this the progress made for this package. I look forward to using it ! -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances
Re: Need a Python 3.8 virtual environment
Hi Steven, On Tue, Mar 02, 2021 at 09:17:36PM -0600, Steven Robbins wrote: > I'm trying to use a (non-Debian) python system built on python 3.8. Debian's > ... > Is there something I've missed? Do you know https://github.com/saghul/pythonz ? I do not use it myself, but a colleague told me he uses that when he needs to test something with every python version available. Hope this helps. -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances
Re: packaging DiscoDOS - a cli tool for vinyl DJs
Hi List, On Sat, May 16, 2020 at 05:32:30PM +0200, Vincent Bernat wrote: > We still have some things better than Ubuntu: > - not converting everything to Snaps Could the fact that Ubuntu is "converting everything to Snaps" impact the current policy that "If someone tries to upload a NEW package, they're always told to go to Debian." ? In other words, could the contribution from Ubuntu to Debian diminishes because more effort is put on Snaps and less effort on improving upstream Debian packages ? [I hope this is not too off-topic for debian-python, feel free to point me to an archived thread somewhere else if you know one]. -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances
Re: DEP 8: Gathering Django usage analytics
Hi List, On Mon, Nov 07, 2016 at 04:32:46PM +0100, W. Martin Borgert wrote: > If Django implements usage analytics, I would strongly suggest to make it > "opt-in" in Debian, just as popcon, not "opt-out". FWIW as a long-time Debian user and supporter, I expect every piece of software I install *not* to report any information about anything on my system without my explicit consent. I am concerned about my online privacy: on my systems even popcon is not enabled and in my browser the CookieMonster and PrivacyBadger extensions are enabled. I would have no problem with Debian packages providing the bits of code that would allow other Debian users to turn on a switch to opt-in on providing upstream with valuable usage data. -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances
Re: static analysis and other tools for checking Python code
On Sat, Mar 05, 2016 at 11:16:28AM +0800, Paul Wise wrote: > On Fri, Mar 4, 2016 at 11:11 PM, Nicolas Chauvat wrote: > > > It does recursively scan for Python files: > > That doesn't pick up Python scripts that don't have .py in their name. I had not noticed that. > I couldn't get it to work with files in the current directory: > > $ touch __init__.py > $ echo 'a = b+1' > bar.py > $ pylint -E . > No config file found, using default configuration Would "pylint -E *.py" do what you want? Or maybe use find with 'file' as a filter? > Should I file bugs about these two issues? You may. I am not part of the maintainers/contributors anymore, so I will not be able to help solve these issues. https://github.com/PyCQA/pylint/ -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances
Re: static analysis and other tools for checking Python code
On Fri, Mar 04, 2016 at 09:33:17PM +0800, Paul Wise wrote: > Do you know if pylint can recursively scan for Python files rather > than being passed the names of Python files? It does recursively scan for Python files: $ tree bar/ bar/ ├── baz │ ├── gloo.py │ └── __init__.py ├── foo.py └── __init__.py $ cat bar/**/*py b = a-1 a = b+1 $ pylint -E bar/ No config file found, using default configuration * Module bar.foo E: 1, 4: Undefined variable 'b' (undefined-variable) * Module bar.baz.gloo E: 1, 4: Undefined variable 'a' (undefined-variable) > Incidentally, I got a patch for c-a-t-t to support pylint from the > author of yamllint: > > https://anonscm.debian.org/cgit/collab-maint/check-all-the-things.git/patch/?id=4dc0a9ca929fa3488ab93cb4e997101d52bbe8a8 Nice! -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances
Re: static analysis and other tools for checking Python code
Hi, On Fri, Mar 04, 2016 at 01:03:17PM +0800, Paul Wise wrote: > > That would be https://pypi.python.org/pypi/PyChecker > > > > Pylint has never run code from the source tree. > > I wonder where I got that impression from. > > What about from the module it is checking? > > > "pylint " should work fine. > > Unfortunately that needs the module installed to work. > > Is there any way to make it scan the source tree instead? It *does* read the source and scan the tree. It *does*not* import or execute the code. That is the very first goal of pylint: "detect code smells in python code by staticaly analyzing the syntax tree read from the source". $ cat foo.py a = b+1 $ pylint -E foo.py No config file found, using default configuration * Module foo E: 1, 4: Undefined variable 'b' (undefined-variable) $ mkdir bar $ mv foo.py bar $ touch bar/__init__.py $ pylint -E bar/ No config file found, using default configuration * Module bar.foo E: 1, 4: Undefined variable 'b' (undefined-variable) There is even a library named https://pypi.python.org/pypi/astroid that was extracted out of pylint to make it easier for other tools to do type inference (and other things) on Python's Abstract Syntax Trees. I hope this helps making clearer what pylint can be used for. I had a look at the README and I suppose the intro section at the top could state the above goal with more clarity. -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances
Re: static analysis and other tools for checking Python code
/Disclaimer: I started pylint with Sylvain Thénault back in 2001, but the project has had new maintainers for a few years./ On Thu, Mar 03, 2016 at 08:06:52AM +0800, Paul Wise wrote: > On Wed, Mar 2, 2016 at 9:23 PM, Nicolas Chauvat wrote: > > > Maybe add pylint? > > As I understand it: > > pylint runs code from the source tree so it isn't suitable for running > by default as that could be a security issue for people reviewing > potentially untrusted code. That would be https://pypi.python.org/pypi/PyChecker Pylint has never run code from the source tree. > pylint isn't able to be run automatically, it needs a human to come up > with the right command-line. "pylint " should work fine. Tuning pylint to a specific coding or project requires human action. One option is to run "pylint -E " to look only for errors. This is also faster. > [Paul Tagliamonte] flake8 has the most mindshare That's not what google trends says https://www.google.fr/trends/explore#q=flake8%2C%20pylint%2C%20pyflakes&cmpt=q&tz=Etc%2FGMT-1 I included pyflakes because flake8's doc says "Flake8 is a wrapper around PyFlakes, pep8 and Ned Batchelder’s McCabe script". The "Design Principles" section from pyflakes' doc states: """Pyflakes is also faster than Pylint or Pychecker. This is largely because Pyflakes only examines the syntax tree of each file individually. As a consequence, Pyflakes is more limited in the types of things it can check.""" To get the list of all the things your installed version of pylint can check for: pylint --list-msgs Github stats prove the pylint project is pretty active https://github.com/PyCQA/pylint/graphs/contributors -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances
Re: static analysis and other tools for checking Python code
Hi, On Wed, Mar 02, 2016 at 11:22:52AM +0800, Paul Wise wrote: > One of the things it has checks for is Python. So far it runs pyflakes > and pep8 Maybe add pylint? -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances
Re: Python and Debian infrastructure
On Thu, Apr 16, 2015 at 02:58:53PM +0800, Paul Wise wrote: > Port services based on Pylons (deprecated) to something else like Django: Pylons is deprecated in favor of Pyramid. It could be that porting these services to Pyramid will be easier than rewriting on top of Django. -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150416123016.gb5...@volans.logilab.fr
Re: PEP 453 affects Debian packaging of Python packages
Hi, On Wed, Sep 18, 2013 at 06:45:24PM -0400, Scott Kitterman wrote: > It shows my background, but when I need older versions of things I > fire up a chroot and work in that. I often do that even for the > same distro release I'm running to keep things separated. It's quite > possible to deal with multiple versions using Debian tools. I had good results doing the something similar, but with LXC to separate things and salt to automate and reproduce the install. https://wiki.debian.org/LXC http://debian.saltstack.com/ -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130919143719.gb6...@volans.logilab.fr
Re: How does team maintenace of python module works?
Hi, On Wed, Feb 20, 2013 at 11:46:31PM -0500, Barry Warsaw wrote: > """ > 9. Git history is a bunch of lies > The primary output of development work should be source code. Is a > well-maintained history really such an important by-product? Most of the > arguments for rebase, in particular, rely on aesthetic judgments about “messy > merges” in the history, or “unreadable logs”. So rebase encourages you to lie > in order to provide other developers with a “clean”, “uncluttered” > history. Surely the correct solution is a better log output that can filter > out these unwanted merges. > """ http://mercurial.selenic.com/wiki/ChangesetEvolution """Changeset Evolution is a set of features to gracefully handle history rewriting operations. It offers a safe and simple way to refine changesets. Results of your local history rewriting operations can be propagated to other clones in a solid way. It is even possible for multiple people to rewrite the same part of the history in a distributed way.""" My humble opinion is that this is about to become a major feature of Mercurial. -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130222131741.ga20...@volans.logilab.fr
Re: How does team maintenace of python module works?
On Wed, Feb 20, 2013 at 06:43:11PM +0100, Piotr Ożarowski wrote: > [Thomas Goirand, 2013-02-20] > > I wouldn't > > mind switching to some different way of doing things if the team finds it > > relevant, and if it is more easy and unified across all packages. If so, > > please tell how you would like to work. We would loose most of the cool > > features I was used to, but so be it... > > does git-buildpackage work with git submodules (with debian dir as a > separate git repo)? FWIW, there is probably a way to implement the same idea with mercurial's subrepo or guestrepo. http://mercurial.selenic.com/wiki/Subrepository http://mercurial.selenic.com/wiki/GuestrepoExtension PS: No, I don't have time to do the work, hence I just mention it exists. -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130220214620.gb13...@volans.logilab.fr
Re: PyCon 2013 -- tentative title/abstract/outline -- feedback plz
On Tue, Oct 02, 2012 at 09:59:32AM -0400, Barry Warsaw wrote: > On Oct 02, 2012, at 02:42 PM, Nicolas Chauvat wrote: > > >As far as I know, pylint already runs with Python3. Doesn't it? > > pyflakes is the one we want to port. May I ask why ? -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121002165715.ga23...@volans.logilab.fr
Re: PyCon 2013 -- tentative title/abstract/outline -- feedback plz
Hi, On Fri, Sep 28, 2012 at 10:40:27AM -0400, Barry Warsaw wrote: > On Sep 28, 2012, at 09:47 AM, Paul Tagliamonte wrote: > > >^^ this is a great idea. It'd be nice if we could prototype a flake8 / > >pyflakes run against the archive, and filter for serious errors > > First, we need to get tools like pyflakes ported to Python 3. It's rather > crazy that pyflakes will complain about print() functions unless you put the > appropriate __future__ import at the top. > > (And actually, several of us are threatening to work on just this at the > upcoming UDS-R in Copenhagen.) As far as I know, pylint already runs with Python3. Doesn't it? -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121002124240.gc15...@volans.logilab.fr
Re: PyCon 2013 -- tentative title/abstract/outline -- feedback plz
Hi Yaroslav, On Wed, Sep 26, 2012 at 11:40:58AM -0400, Yaroslav Halchenko wrote: > To not be too ambitious and to not invest too much time I have decided to > submit only a talk. Here follows a perspective title, abstract and some > notes/outline which will not be a part of submission. I would really > appreciate (and of cause would acknowledge in the slides) any feedback, ideas, > comments, etc. I suggest you would also try to describe the differences between The Complete Python Distribution On Debian and the others ways there are to install Python packages. When I say "I do not need all this easy_install, pip, virtualenv, distribute/packaging, buildout, /etc/ for I have Debian!", I am usually told: - but we have to work on Windows - but we are not root on the computer we are using and can't run apt-get - but I want a newer version of X than the one included in Debian - but I am not doing deployment/production and for development I need the latest versions of these modules because this component I rely on says so - I am preparing things for production, so I need everything to be reproducible independently of the underlying system - etc. I think being prepared to answer these questions and maybe address some of these issues directly in your slides would help make clear what Debian is a good solution for. Possible answers are: - windows: if it hurts, stop doing it and install virtualbox :p - not root: try a virtual machine (or maybe a variant of chroot?) - newer: are you ready to handle all the compatibility/dependency problems on your own ? - dev: packaging python modules is easier than getting a full distribution to work right, take a look at the GSoC project that packages PyPI/*, your new-and-shiny stuff is probably there - prod: you want a chroot or a virtual machine. - etc. Hope this helps, PS: by the way, would anyone know of a way to use chroot or something similar to allow any user to have any number of virtual environments that use apt-get to install stuff and fall-back to the system if something is not installed in the virtualenv ? -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121002080148.ga4...@volans.logilab.fr
Re: Request for Review - Nuitka the Python compiler (status update, more questions)
Hello, On Wed, Nov 16, 2011 at 09:48:21AM +0100, Kay Hayen wrote: > I also renamed the "act alike python" binary "/usr/bin/Python" to > "/usr/bin/nuitka-python" as a result of the review. Nice. > So that is it, I don't know anymore of things to do. What about a > manpage, is it considered mandatory? It is always better to have one. Do you know about rst2man that can generate a man page from restructuredtext ? -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2016094141.ga10...@volans.logilab.fr
Re: Request for Review - Nuitka the Python compiler
Hello, On Tue, Nov 15, 2011 at 11:59:56PM +0100, Kay Hayen wrote: > Oh collective Debian-Python Brainpower, tell me a good name but > "nuitka" for said binary. :-) Reading the doc I understand that "Python" == "Nuitka.py --execute". Am I correct ? Maybe Python + nuitka --> nuitka + nuitka-ctl OrPython + nuitka --> pynuitka + nuitka OrPython + nuitka --> nuitka + "nuitka compiler" OrPython + nuitka --> nython + nuitka Or something better than the above :) -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2015233524.ga27...@volans.logilab.fr
Re: Request for Review - Nuitka the Python compiler
Hi, On Sat, Nov 12, 2011 at 10:50:13PM +0100, Jakub Wilk wrote: > * Paul Boddie , 2011-11-12, 15:08: > >>c) I renamed "Nuitka.py" to a "nuitka" binary. I am keeping the > >>drop-in replacement as "Python" though. > >I don't think it's wise to call it "Python", > > Agreed, this is bad idea. +1 What's wrong with calling nuitka, nuitka ? I do not remember PyPy, Stackless, Jython, IronPython or any other alternative Python interpreters trying to install their executable under the name /usr/bin/python, so why would you want to do it in this case ? PS: Thank you for working on Nuitka, it looks really interesting. -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2015172854.gd3...@volans.logilab.fr
Re: Request for packaging - Nuitka the Python Compiler
Hi, Thank you Kay for Nuitka. I have not tried it, but I will since it looks interesting. On Thu, Oct 13, 2011 at 11:29:09AM +0800, Paul Wise wrote: > > Currently I am just trying to be a good upstream. > > On that topic, we have a bunch of good links and some Debian-specific > information about how to be a good upstream here: > > http://wiki.debian.org/UpstreamGuide > > I would personally add "don't use SCons" that If and only if you were to consider replacing SCons, take a look at waf that has many qualities. http://code.google.com/p/waf/ -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111013071822.gb5...@volans.logilab.fr
Re: Current state of packaging Python software for Debian (was: list of package for python_support -> dh_python2 ?)
On Tue, Jun 14, 2011 at 03:44:33PM +0200, Josselin Mouette wrote: > Le mardi 14 juin 2011 à 07:39 -0400, Barry Warsaw a écrit : > > Blog references, email threads, or other links to existing artifacts would > > be > > very helpful. Has anybody ever written a "What's Wrong With Python and How > > It > > Hurts Debian" article? > > I have something like that among the things I’d like to write, but it > would be very long so I haven’t found the time yet. Maybe you could find the time to write the table of contents ? That would make it easier for other to try to fill the gaps. -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110614142709.ga8...@volans.logilab.fr
Re: Switching to git
On Sun, Mar 06, 2011 at 05:30:15PM -0500, Yaroslav Halchenko wrote: > > Wouldn't managing python packages with mercurial make sense? > > it would as much as with any other DVCS, such as GIT. I am yet to hear > any objective advantage for using Python-based DVCS because they are > written in Python to maintain python packages Being a maintainer of Python packages often means you know Python which enables you to make mercurial work the way want: write a plugin, write a script that looks for information in the repo, etc. from mercurial import hg, ui repo = hg.repository(ui.ui(), dirname) changed = repo.status() # do something with changed... This proved *very* valuable over the years to get things done very quickly when working with a large number of mercurial repositories and was much faster than writing bash scripts that run the hg command. Now, I heard the argument about being the user of a DVCS rather than hacking that DVCS, I do not intend to fight against the large amount of people that know git (a majority maybe?), want git to be used everywhere (some would like to have hg used everywhere, don't they) and do not want to learn hg (it is true that comparing the two can take a bit of one's time, because they are so similar). Doesn't matter, I'll use http://hg-git.github.com/ if I need to ;) -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110307101942.ga4...@volans.logilab.fr
Re: Switching to git
On Sun, Mar 06, 2011 at 01:48:32PM +, Sandro Tosi wrote: > On Sun, Mar 6, 2011 at 11:12, Vincent Bernat wrote: > > There was some discussions about switching from SVN to git. CPython just switched to mercurial. Mercurial works well with multiple repositories (subrepo extension) and handles well patches (mercurial queues). Wouldn't managing python packages with mercurial make sense? -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110306202118.ga12...@volans.logilab.fr
Re: Testing Python modules (was Re: Numpy API change?)
On Thu, Jul 29, 2010 at 11:23:05AM -0400, Barry Warsaw wrote: > True. I like separating my tests into submodules, and I don't personally like > in-docstring doctests, so I'm biased toward those decisions. I'd say in-docstring doctests are good at documentation rather than extensive testing. -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100730091616.gc4...@volans.logilab.fr
Re: Python Testing -- should be there uniformity?
On Tue, Jul 27, 2010 at 09:48:25PM -0400, Yaroslav Halchenko wrote: > well, both "setup.py test" and "module.test()" sound like reasonable Have you guys been following the recent discussion on the Testing-In-Python mailing-list? This topic was discussed at length. http://lists.idyll.org/pipermail/testing-in-python/2010-February/002659.html looks like a good start. Just checking valuable info/input does not get lost :) -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100728082910.gb4...@volans.logilab.fr
Re: continuous integration/testing for python packages [Was: Is it worth back porting PEP 3147...]
On Tue, Apr 27, 2010 at 11:07:51AM -0400, Barry Warsaw wrote: > On Apr 27, 2010, at 10:01 AM, Nicolas Chauvat wrote: > There's also buildbot of course, which I guess it the granddad of Python CI > tools, kind of. Yes, buildbot is the old-timer and has loads of features. As far as I know, extracting information out of buildbot is more difficult than it is with a tool like Apycot that's built on top of CubicWeb. > Are there things like a API (REST or otherwise) for pulling data out of > apycot? Sure, that's a basic functionnality of CubicWeb. For example, just take any url and append vid=xml http://apycot.hg-scm.org/projectenvironment/hg/full/108464 becomes http://apycot.hg-scm.org/projectenvironment/hg/full/108464?vid=xml If the data that's extracted isn't what you expect, file a ticket at logilab.org/project/apycot and the 'xml' view will be enhanced. As you could read from http://www.cubicweb.org/blogentry/779839 the views you apply to data sets are not restricted to producing html or xml, they can also directly produce json or pdf, graphs, etc. Other examples of the view mechanism would be the ones that use a specific vocabulary as in http://www.logilab.org/project/apycot?vid=doap or http://www.cubicweb.org/blogentry/779839?vid=sioc or http://www.cubicweb.org/cwuser/nchauvat?vid=foaf In short, CubicWeb was *designed* to publish its data under reusable formats, html being just one way to present data. Maybe we can restrict this part of the discussion to the cubicweb mailing list ? > I'm not familiar with __pkginfo__.py, __pkginfo__ is a declarative format used at Logilab. http://hg.logilab.org/logilab/devtools/file/tip/doc/pkginfo_variables.txt > We need a declarative syntax that can be consumed by more tools, > which is why I'm so excited about Tarek's work in distutils-sig. I agree, Tarek's work is a great improvement over the current situation. > Is there a wiki or online documentation documenting these tools, or is it all > in the source? It is mainly in the source. You will find several people that will be happy to help if you ask your questions on python-projects at lists.logilab.org. > Is that easy work manual or automated? What does it take to Debianize > random-simple-pypi-package? (By that I mean "run a script" or "inspect > setup.py and write the debian/*" or "...?". Easy manual work. I'm cc'ing the people that do it often so that they can provide details. Alexandre, Sylvain ? -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100427200947.ga15...@volans.logilab.fr
continuous integration/testing for python packages [Was: Is it worth back porting PEP 3147...]
Hi, [discussion started at http://lists.debian.org/debian-python/2010/04/msg00046 should we continue or trim some of the cc'ed lists ?] On Mon, Apr 26, 2010 at 06:41:16PM -0400, Barry Warsaw wrote: > On Apr 26, 2010, at 06:35 PM, Nicolas Chauvat wrote: > >On Thu, Apr 22, 2010 at 01:52:11PM -0400, Barry Warsaw wrote: > >> How much of the transition testing is automated? It would be very > >> interesting > >> for example, to have a test framework that could run any combination of > >> Python > >> packages against various versions of Python, and get a report on the > >> success > >> or failure of it. This may not be a project for the distros of course - I > >> think upstream Python would be very interested in something like this. For > >> example, a tool that grabbed packages from the Cheeseshop and tested them > >> against different versions would be cool. If snakebite.org ever gets off > >> the > >> ground, that might be the best place to put something like this together > >> (though we'd care less about OSes that aren't Debian and Ubuntu). > > > >Unfortunately, Logilab does not have much man-power to offer to set > >this up at the moment, but would something like > >http://apycot.hg-scm.org/ fit your description of a test framework ? > > That's for continuous integration of Mercurial, right? Yes. > >We also have it running at logilab.org and cubicweb.org of course: > >http://www.logilab.org/view?rql=testconfig&vid=summary > >http://www.cubicweb.org/view?rql=testconfig&vid=summary > > > >As you can see with these second and third links, tests include > >lintian and piuparts checks. > > > >Is it something like this that you had in mind? > > Yes. What are you using to drive this? I'm not really up on CI tools, but > Hudson has been getting a lot of buzz. > > http://hudson-ci.org/ We are using http://www.logilab.org/project/apycot that is GPL software mainly developed and maintained by Logilab, but slowly reaching out to a larger audience. It uses a web framework to store the information in a db and provide a web user interface, plus slave testing bots running on one or more hosts that get the next task from the queue, execute it and store the results in the db. > What I like about your display is that a failure in one area does not > necessary mean a failure elsewhere. That way you can better see the overall > health of the package. You may find interesting the following blog posts about apycot and ways to display its information http://bit.ly/9dZQQE > as nearly automatic and effortless packaging in Debian and Ubuntu. We tried fully automatic packaging of Python programs years (8?) ago and did not succeed for distutils and setuptools were too far away from Debian packaging concerns. Introducing in mypackage/__pkginfo__.py and mypackage/setup.py all the information needed to generate the debian/* files without the need to modify them eventually meant more or less copying their whole content, for their is actually not much to generate. It also meant using a less efficient toolchain because of the added conversion step. We moved to having tools that check the consistency of the information provided by __pkginfo__ and debian/* files and make it easier to build the Debian packages. These tools are http://www.logilab.org/project/logilab-devtools Packaging a piece of Python software now requires a bit of (easy) work at first, but following releases only need one or two commands. And all the dh_python* helper scripts reduced that work even further. > What I have in mind is defining a set of best practices, embodied as much as > possible in tools and libraries, that provide carrots to Python developers, so > that if they adhere to these best practices, the can get lots of benefits such > ... > It's things like 'python setup.py test' just working, and it has an > impact on PyPI, documentation, release management, etc. These best > practices can be opinionated and simple. If they cover only 80% of > Python packages, that's fine. Developers would never be forced to > adhere to them, but it would be to their advantage to do so. Sounds good to me :) -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances Full link to blog posts: http://www.cubicweb.org/view?rql=Any+X+WHERE+X+is+BlogEntry%2C+T+tags+X%2C+T+name+%22apycot%22 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100427080128.gc4...@volans.logilab.fr
Re: Is it worth back porting PEP 3147 to Python < 3.2?
Hi Barry, Nice to see someone of the core python team taking part in distribution development. On Thu, Apr 22, 2010 at 01:52:11PM -0400, Barry Warsaw wrote: > How much of the transition testing is automated? It would be very interesting > for example, to have a test framework that could run any combination of Python > packages against various versions of Python, and get a report on the success > or failure of it. This may not be a project for the distros of course - I > think upstream Python would be very interested in something like this. For > example, a tool that grabbed packages from the Cheeseshop and tested them > against different versions would be cool. If snakebite.org ever gets off the > ground, that might be the best place to put something like this together > (though we'd care less about OSes that aren't Debian and Ubuntu). Unfortunately, Logilab does not have a much man-power to offer to set this up at the moment, but would something like http://apycot.hg-scm.org/ fit your description of a test framework ? We also have it running at logilab.org and cubicweb.org of course: http://www.logilab.org/view?rql=testconfig&vid=summary http://www.cubicweb.org/view?rql=testconfig&vid=summary As you can see with these second and third links, tests include lintian and piuparts checks. Is it something like this that you had in mind? -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100426163526.gb26...@volans.logilab.fr
Re: Ideal directory structure?
On Sat, Jan 30, 2010 at 08:14:07AM +0530, Umang wrote: > How do you structure your folders? Here is an example of what we have been happily doing for a decade http://hg.logilab.org/pylint/file/5b9f4a9524ab pylint/ config.py gui.py lint.py [...] bin/ pylint (executable that does `from pylint import config`) There is only one level: it is simple. Just set PYTHONPATH to get it working without installing anything on your system -> works both for development purposes and for locally using it (i.e, since it depends on logilab/common, put them side-by-side). `python setup.py install` works as expected, but is not required to try out the software. Debian packaging will move files around as it wishes anyway. PYTHONPATH is zen: import this and stay away from setuptools ! -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Python 2.6 in unstable
On Sun, Nov 08, 2009 at 03:22:09PM -0600, Kumar Appaiah wrote: > Dear Debian Python, > > Most of the Python 2.6 transition bugs have been fixed, and the Nice work. -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: XS-Python-Version vs pyversions
On Tue, Sep 08, 2009 at 09:53:09AM -0400, Scott Kitterman wrote: > On Tue, 08 Sep 2009 12:21:07 +0200 Bernd Zeimetz wrote: > >There was a policy process? > > Apparently we still need one of these. Can we work on solving this? I > think having a mechanism to create an actual current, maintained Python > policy is a pre-requisite to solving a lot of these problems. +1 -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: VCS for Python code Was: Trac team almost dead?
Hi, On Wed, Sep 02, 2009 at 12:15:44AM +0800, Chow Loong Jin wrote: > Git has #1, by the way, if I'm understanding you correctly. Which means both > ... > In my case, the more I read about Mercurial, the more I dislike it, but > that's a > different matter. I'm not sure anyone cares, but at Logilab we have been happy users of Mercurial for several years now. My bet is that git and hg are the two dvcs that will survive the current crunch that follows the vcs explosion which happened a few years ago. And Mercurial being written in Python makes it easier to hack into it when needed. -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: will 2.6 be default?
On Wed, Aug 26, 2009 at 09:20:51PM +1000, Ben Finney wrote: > I'm confident that, if the right coordination of effort and publicity of > the necessary to-do tasks were applied, there would be ample willingness > From Debian members who want Python 2.6 in Debian Squeeze. It would indeed be nice if someone could list the hurdles that stand between us and Python 2.6 in Squeeze, or point us to the web page that lists them. Python2.6 is in experimental: http://packages.debian.org/source/experimental/python2.6 Python2.6 is in Ubuntu jaunty: https://lists.ubuntu.com/archives/ubuntu-devel/2009-May/028266.html Has anything changed since: http://lists.debian.org/debian-python/2009/03/msg00091.html and: http://lists.debian.org/debian-python/2009/08/msg3.html ? I read the list and can search the archives, but have not found a list of tasks that need doing to get 2.6 in squeeze. -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dh-make-python
Hello Debian Pythonistas, On Sat, Aug 01, 2009 at 10:11:30PM +0200, Piotr Ożarowski wrote: > [David Bremner, 2009-08-01] > > I was recently chatting with Sandro Tosi on IRC about the > > non-existance of a python equivalent to dh-make-perl > > http://github.com/astraw/stdeb/tree/master I can see stdeb mentions logilab-devtools in its background section. Thank you :) logilab-devtools_ provides a command named lgp that uses metadata stored in __pkginfo__.py to make (much) easier the job of the Debian Developer packaging python programs. Once the thing is set up, we usually type: lgp build -d lenny,squeeze,sid,hardy,jaunty to get packages for all these distributions. For a description of the __pkginfo__ format, see pkginfo_variables_ As you surely know, packaging is a hot topic in the Python community at the moment. In case this did not appear on your radars yet, here are 3 PEPs and a couple blog entries: PEP-345_ Metadata for Python Software Packages 1.2 PEP-386_ Changing the version comparison module in Distutils PEP-376_ Changing the .egg-info structure `Words on distribute`_ by Tarke Ziade `The Configuration Management Problem`_ by myself Hope this helps converging towards efficient packaging for all, references: .. _logilab-devtools: http://www.logilab.org/project/logilab-devtools .. _pkginfo_variables: http://hg.logilab.org/logilab/devtools/file/314b315d9bba/doc/pkginfo_variables.txt .. _PEP-345: http://www.python.org/dev/peps/pep-0345/ .. _PEP-386: http://www.python.org/dev/peps/pep-0386/ .. _PEP-376: http://www.python.org/dev/peps/pep-0376/ .. _`Words on distribute`: http://tarekziade.wordpress.com/2009/07/24/words-on-distribute-distutils-pep-376-pep-386-pep-345/ .. _`The Configuration Management Problem`: http://www.logilab.org/blogentry/9860 -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: what's keeping python2.6? why is Josselin acting like a deaf man when his packages contain critical bugs?
On Mon, Jul 06, 2009 at 12:06:15PM +0200, Jan Geboers wrote: > If "tens or hundreds" of people are asking the same question > maybe it would be a good idea to state a public answer to said question on > the python mailing list? Yes, it would be. Asking such a question on this list, you have a much higher probability to get the answer you want than by coming forward saying that X is not doing the job you expect him to do on his spare time. Of course, asking Google first is always the right thing to do. Here is what you find by googling for two minutes: http://lists.debian.org/debian-python/2009/03/msg00091.html https://lists.ubuntu.com/archives/ubuntu-devel/2009-May/028266.html If that does not answer the question, try the following for more links http://www.google.com/search?q=python+2.6+debian+package+site:lists.debian.org Since I do not know the actual answer to the "what's keeping python2.6 out of testing/unstable?" question, I cannot provide it, but I am sure someone else will be able to give more details than Sandro just did. As for any free software project, the question that the developers expect is "I see python2.6 is not in testing/unstable yet. I read the following discussion in the archives. I looked at the package. If I understand correctly this and that need to be done in order to get the thing to work. Is it ok if I proceed? Who wants to review my work?". I bet that this question will get you an immediate answer 99.9% of the times you ask it. -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: what's keeping python2.6? why is Josselin acting like a deaf man when his packages contain critical bugs?
Hi, On Sun, Jul 05, 2009 at 07:34:21PM +0200, Jan Geboers wrote: > But if both the python maintainer and the maintainer of the individual > package can't be bothered to reply to e-mails or read their bug report that > is marked critical, Every day, each and every one of us receives *tons* of e-mails. I just got 200 this morning (after spam filtering). 200*5 minutes is more minutes than are available in a day. What makes you think your e-mail was worth replying to? Out of the thousands of Debian+Python users, it could very well be that tens or hundreds are asking this same question at the same time, why would someone bother to reply to everyone? > what more can be done? It's hard to help if you have no clue about where the > problem or high workload is situated. Sandro answered that question, please read his e-mail again. -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: python package installation problem
On Mon, Jun 22, 2009 at 07:25:54PM +0200, Piotr Ożarowski wrote: > > rm -r /usr/share/pyshared/something > > NEVER DO THAT > > > rm -r /usr/lib/python-2.?/site-packages/something > > almost never do that > > If your package leaves pycental leftovers, use preinst scipt to > remove /usr/lib/python-2.?/site-packages/foo (see archives for more > details, "rm" command will not be necessary in most cases) - you have to > be sure no other package is using "foo" namespace, though I was describing a way to fix an installation broken by a package that did not do the right thing when migrating from central to support. I was not recommending this as the Right Thing to do in all cases. In my case, running 'pycentral pkgremove something' by hand failed to fix the situation once the package with broken upgrade path was installed. -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: python package installation problem
On Mon, Jun 22, 2009 at 11:00:08AM -0400, Sancar Adali wrote: > I had manually deleted those site-packages directories in order to fix > an apt problem. In /usr/share/pyshared I see none of the gtk2 or > gobject files. > cd /usr/share/python-support/ I have directories for python-gtk2 and > python-gobject. > Is the easiest thing to do remove python-2.4/5 and reinstall them Unless you already deleted something you should not have deleted, rm -r /usr/share/pyshared/something rm -r /usr/lib/python-2.?/site-packages/something should be enough to solve your problem. If that doesn't work, purging packages and reinstalling is probably the easiest thing to do. -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: python package installation problem
Hi Sancar, On Sun, Jun 21, 2009 at 08:53:07PM -0400, Sancar wrote: > I might have broken something with python-central or something, when I > was fixing a weird dependency error. It's a long story. If there's a way > to fix this problem quickly, I would really appreciate it. It is easy to mess up a package transitioning from python-central to python-support. You should look into your /usr/lib/python2.?/site-packages directory. If you find broken symlinks to /usr/share/pyshared/something, *check*twice* then remove the said something directory and Python will find the package installed by python-support. -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Butchered python configuration ...
On Wed, Apr 29, 2009 at 10:50:54PM +1200, itsovermyhead wrote: > I think this is incorrect use of the colon Froggy. > [...] $ tail -n 4 .procmailrc :0: * ^From: itsovermyhead /dev/null $ echo "Get a life." -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: help with writing a PEP to ease software distribution
On Wed, Oct 01, 2008 at 11:33:03AM +1000, Ben Finney wrote: > Huge thanks to Josselin Mouette +10 -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
help with writing a PEP to ease software distribution
Hi List, I started with a troll on the pycon-uk list. The discussion landed on distutils-sig. It looks like it may end up with something good. Here are the public threads: http://mail.python.org/pipermail/distutils-sig/2008-September/010007.html http://mail.python.org/pipermail/distutils-sig/2008-September/010010.html Here is where we stand today: http://mail.python.org/pipermail/distutils-sig/2008-September/010126.html Could some people from the Debian-Python team help out with this? At Logilab, we have been making Python packages for years, but we are not the authors of python-support nor python-central nor the Debian Python Policy and what would be really nice were that these people contribute to the PEP for they have even more experience than we do. Making a consistent and spell-checked document and advocating it I can do. Doing the necessary reading, testing and writing it alone I do not have time. Would you mind joining the discussion on distutils-sig at http://www.python.org/community/sigs/current/distutils-sig/list/ ? -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#197871: Bug#197875: python2.3: module dbm is missing
Encolpe DEGOUTE wrote: Not, just my boss. I will try to convince him to use bsddb. Thanks for all. You may also suggest Stéphane to use http://www.logilab.org/pylint to check that your code complies to your company's coding standard. -- Nicolas|\ _,,,---,,_ CHAUVAT ZZzz /,`.-'`'-. ;-;;,_ |,4- ) )-,_. ,\ ( `'-' '---''(_/--' `-'\_)
Re: Errors of Zope in BTS
Andreas Tille wrote: Is anybody willing and able to join a task force to reduce BTS entries of Zope? I'm willing to try. -- Nicolas|\ _,,,---,,_ CHAUVAT ZZzz /,`.-'`'-. ;-;;,_ |,4- ) )-,_. ,\ ( `'-' '---''(_/--' `-'\_)
Re: bug reports preventing the python transition
Thomas Viehmann wrote: For some reason zope webmail products don't seem to last very long. If there's need for a replacement, I could ITP the nuxeo groupware suite. They seem to have incorporated the (french) WebMail product. The license needs some investigating (5*GPL, 2*something in LICENSE.txt) , but that is IMO the only zope webmail amongst those I now that has any chance. If that's a webmail you want, you may just package http://www.zope.org/Members/maraf/WebMail which is what's used by Nuxeo. Of course, Nuxeo Groupware suite provides more than webmail and would be even more valuable if it wasn't so dependent on their Collaborative Portal Server which is incompatible with current CMF... and I was told that this suite is only alpha at the moment. Be sure to contact them before you ITP it... sf at nuxeo.com should answer quickly. -- Nicolas|\ _,,,---,,_ CHAUVAT ZZzz /,`.-'`'-. ;-;;,_ |,4- ) )-,_. ,\ ( `'-' '---''(_/--' `-'\_)
