On 15 November 2011 23:49, Kay Hayen kayha...@gmx.de wrote:
Hm, what about nuitka-python as a binary name of what is now Python, is
that OK? It seems the readable variant.
nuitka-python is what I'd call it, from your description. I'm not actually
a Debian packager, though.
Thomas
with the process. Can someone point me to the best way to
submit the packaging change to Debian, bearing in mind that I'm not really
familiar with the procedures and terminology around Debian?
Thanks,
Thomas Kluyver
Thanks, Yaroslav,
On 9 March 2012 14:31, Yaroslav Halchenko deb...@onerussian.com wrote:
the best way would be to join Debian Python Modules Team and help
maintaining this library in Debian by directly committing to team's SVN
repository and then seeking review/sponsorship.
I'll try to
On 12 March 2012 14:49, Yaroslav Halchenko deb...@onerussian.com wrote:
well -- it might be beneficial meanwhile to share your changes one way
or another (patch, git, mentors) so someone could review them
OK, I've attached the patch (against the debian/ directory) to this e-mail.
The built
On 13 March 2012 21:40, Julian Taylor jtaylor.deb...@googlemail.com wrote:
thanks for the patch, I have applied it to the team repository along
with some more minor fixes to other parts of the package.
http://anonscm.debian.org/viewvc/python-modules/packages/python-tornado/trunk/
Great,
On 14 March 2012 04:13, Scott Kitterman deb...@kitterman.com wrote:
I did have to make some additional changes, such as using a policy
compliant
binary name in python3, as we did for PyQt4 (python3-pyqt4.qsci) and using
dh_sip3 for the python3 package. You can see the details in the DPMT SVN
After some trial and error, I've got it building python3-numpy
(leaving python-support in place for Python 2) - a patch is attached.
I've checked that I can install and import the built package.
Changes and suggestions are welcome, and I expect there are better
ways to do bits of it. I'm away for
On 16 March 2012 13:35, Sandro Tosi mo...@debian.org wrote:
Thanks a lot for your work! I just gave it a quick look (i.e. reading
the patch) and it seems that would work (at least for the packaging
part). It would be also nice if you could post your patch at
601...@bugs.debian.org, so also the
On 17 March 2012 15:00, Sandro Tosi mo...@debian.org wrote:
that stuff is done and the package is uploaded: Thanks for your contribution!
Great, thanks for putting in the time to finalise it.
Thomas
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of
On 28 March 2012 21:10, Jakub Wilk jw...@debian.org wrote:
I see that you disabled tests for zoneinfo, which I interpret as a yes
answer to my question. Well, I can't see how such behaviour is useful[0],
but at very least it deserves a big red warning in README.Debian.
As far as I can see, the
On 1 April 2012 10:53, Jakub Wilk jw...@debian.org wrote:
Wouldn't it be better to update zoneinfo.gettz() tests to use tz.gettz(),
instead of disabling them entirely?
Please add get-orig-source target.
The copyright file mentions dateutil/zoneinfo/zoneinfo-2011d.tar.gz, which
doesn't exist
On 2 April 2012 23:23, Jakub Wilk jw...@debian.org wrote:
Your get-orig-source target tries to support being invoked from any
directory, but this doesn't work:
You're right. I've used `pwd` now instead of . and it appears to work.
I was following the example here:
On 4 April 2012 22:14, Jakub Wilk jw...@debian.org wrote:
Hmm, didn't help here:
No bright ideas. What uscan version do you have?
$ uscan --version
This is uscan, from the Debian devscripts package, version 2.11.6ubuntu1
I took a closer look at your watch file:
I've followed all of your
On 5 April 2012 11:38, Jakub Wilk jw...@debian.org wrote:
Indeed, adding --check-dirname-level=0 fixes the problem for me.
I've added that, and checked that it still works for me.
Thanks,
Thomas
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe.
On 14 April 2012 11:12, Jakub Wilk jw...@debian.org wrote:
Could you update the latter item?
Yep, done.
Thomas
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
On 16 April 2012 21:30, Jakub Wilk jw...@debian.org wrote:
The extended description is supposed to make sense even when it's displayed
alone, without the synposis. So it certainly cannot start with “It
features:”.
Done. I'd misunderstood the format, I thought that it was simply
continuation of
On 18 April 2012 18:03, Jakub Wilk jw...@debian.org wrote:
But anyway, I bumped timestamp in the changelog, built, signed and uploaded
the package. Thanks.
Thanks Jakub, and thanks for taking the time to go through all these
things with me.
Thomas
--
To UNSUBSCRIBE, email to
On 4 May 2012 19:06, Dmitrijs Ledkovs x...@debian.org wrote:
ok. what is the relationship between 'distribute' 'packaging'?
Let's see if I get all these right:
distutils: basic packaging functionality, part of the Python standard library
setuptools: third party module to add functionality that
On 4 May 2012 23:33, Tim Michelsen timmichel...@gmx-topmail.de wrote:
how to solve pbuilder-satisfydepends-dummy dependencies?
https://answers.launchpad.net/ubuntu/+source/pbuilder/+question/196073
Looking at which packages it says aren't installable, I would guess
that your pbuilder
)?
Package name: python-notify2
Version : 0.3-1
Upstream Author : Thomas Kluyver tho...@kluyver.me.uk
URL : http://pypi.python.org/pypi/notify2
License : BSD
Section : python
It builds these binary packages:
python-notify2 - Desktop notifications API
On 14 May 2012 23:27, Thomas Kluyver tho...@kluyver.me.uk wrote:
- The tests: Running the tests during the build requires dbus and a
notification daemon, which in turn requires an X server running. I've
come up with a recipe that works in a pbuilder, but is it suitable for
the autobuilders
On 19 May 2012 15:20, Piotr Ożarowski pi...@debian.org wrote:
if you're not sure and package works with all Python{,3} versions
currently supported by Debian, it's OK to skip these fields
As far as I know, that's the case. The tests pass with all supported versions.
uploaded
Thanks, Piotr!
On 19 May 2012 18:19, Barry Warsaw ba...@python.org wrote:
Ideally, upstream would mock these for the majority of, if not all the tests.
It would be fine if there were non-unittests (i.e. integration tests) that
used the real dbus, but these could be disabled for the builds.
(Upstream is also
On 19 May 2012 19:00, Thomas Kluyver tho...@kluyver.me.uk wrote:
So the
most important thing for the tests is to check my interpretation of
the notifications spec against an established implementation. That's
simple enough for local testing (I just see a series of
notifications), but doing
On 25 May 2012 15:39, Thomas Kluyver tho...@kluyver.me.uk wrote:
Should I try to launch the dbus server for my tests (like I'm already
launching the notification daemon), or just disable all the tests
which require a running dbus server (which is all of them, at
present)?
I've disabled
On 28 May 2012 12:05, Thomas Kluyver tho...@kluyver.me.uk wrote:
Alternatively, if
there's a good way to get dbus running on the buildd, I'd be happy to
re-enable the tests.
Thanks to Jakub for a patch which should sort it out. I've applied it in svn.
Thomas
--
To UNSUBSCRIBE, email
On 6 June 2012 11:51, Toni Mueller t...@debian.org wrote:
Since some time, it's Plone
4.[01] that requires Python 2.6. Only the still-in-beta Plone 4.2
even works with Python 2.7 (but 2.6 is still supported).
For my own interest, what does the current version do that prevents it
from
On 7 June 2012 17:09, Michael Fladischer mich...@fladi.at wrote:
SVG converter based on Cairo
This description seems a bit ambiguous - does it convert from or to
SVG? What's the format on the other end of the conversion? But perhaps
this is obvious to anyone who'd want to install it. Clicking
On 22 June 2012 08:47, Dmitry Shachnev mity...@gmail.com wrote:
There is a small test script in the tarball (I plan to add real
unit-tests in the next releases), but it requires dbus and
gnome-keyring daemons running, so I don't think it's possible to run
it at the build time.
I recently did
On 22 June 2012 12:37, Simon McVittie s...@debian.org wrote:
FYI this shouldn't be necessary on Linux if you're either under X or
running dbus-daemon manually, but it's still needed on kFreeBSD and
probably Hurd, even if you run dbus-daemon manually.
The tests failed during an archive rebuild
The attached diff updates pyxdg with a new upstream version, which
includes Python 3 support (bug #591017).
I'm not sure of the etiquette for doing this sort of thing. Should I
contact the list (like this), directly contact the individual named as
the uploader - in this case, Piotr Lewandowski -
On 31 July 2012 08:02, Jakub Wilk jw...@debian.org wrote:
If the team is in the Maintainer field, you are invited to commit and upload
stuff yourself. However, in case of big or controversial changes (*cough*
#654978 *cough*) it's still a good idea to ask the human maintainer(s)
first.
Do
Thanks Barry,
On 1 August 2012 19:51, Barry Warsaw ba...@python.org wrote:
- I bumped d/compat to 9 and BD on debhelper = 9
- In the d/control python-xdg and python3-xdg stanzas, I added the appropriate
Python 2 or Python 3 text in the first line of Description:
I've applied both of these,
Hello,
I'd like to request a sponsor to upload a new version of pyxdg.
Package name: pyxdg
Version : 0.23-1
Upstream Author : Sergey Kuleshov svyato...@gentoo.org; Heinrich
Wendel h_wen...@cojobo.net; Thomas Kluyver tho...@kluyver.me.uk
URL : http://freedesktop.org/wiki
On 10 August 2012 11:33, Jakub Wilk jw...@debian.org wrote:
I'm confused. Why do you ask _us_ if you can inject a package into Debian
Med repo?
I think he's checking that it's OK to get help here with some
packaging that won't live in the DPMT repository. That's presumably
fine, but if he's not
Hi Nigel,
On 3 September 2012 14:57, Nigel Sedgwick n...@camalg.co.uk wrote:
The application makes heavy use of numpy and wx and will soon make heavy
use of scipy, matplotlib and various other python libraries that are
widely used.
Python 3 versions of numpy and scipy are already in wheezy.
On 18 September 2012 18:00, Dmitry Smirnov only...@member.fsf.org wrote:
At the moment I can't recall a good example but there are some exceptions like
when package in mainly used as application.
IPython is packaged as 'ipython', 'ipython3', etc., and it also
includes a public module.
Thomas
With apologies in advance for straying off topic ;-)
On 21 September 2012 14:18, Yaroslav Halchenko deb...@onerussian.com wrote:
Previously I have done a similar talk with an accent on a scientific
Python stack in Debian [1] which I thought was quite well accepted.
We're having a big
On 21 September 2012 19:32, Paul Boddie p...@boddie.org.uk wrote:
From following discussions on python-dev, I imagine that it might be
interesting for people to be shown how following the basic best practices
around metadata and configuration information can get you most of the way to
making a
On 2 October 2012 09:01, Nicolas Chauvat nicolas.chau...@logilab.fr wrote:
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
The attached patch is a first stab at packaging SymPy 0.7.2, which
supports Python 3. There's some polishing to be done, such as adding
an isympy3 script, but it at least builds.
I assume that building the binary packages from a single source
package is preferred? The upstream releases on Google
On 26 October 2012 09:19, Floris Bruynooghe f...@devork.be wrote:
Several people have said they don't think this is a good idea. But
why not? There is a bad effect if you don't rewrite the shebang to
/usr/bin/python[3] -ES that we know of, but is there any example of
where such a shebang
On 26 October 2012 11:53, Chow Loong Jin hyper...@debian.org wrote:
What is the definition of system script?
Any script installed via dpkg, perhaps?
I wouldn't have said so - I install plenty of Python scripts from
packages, like /usr/bin/ipython, that I wouldn't call system scripts.
I don't
On 26 October 2012 14:20, Paul Tagliamonte paul...@debian.org wrote:
django-admin if I'm using a virtualenv? Perhaps I'm missing the point?
Will this just break all virtualenv support?
To my mind, django-admin is not a system script. A system script would
be something like the
On Oct 25, 2012 6:31 PM, Thomas Kluyver tho...@kluyver.me.uk wrote:
I assume that building the binary packages from a single source
package is preferred?
sympy devs reckon we should use the separate release tarballs. Is that
acceptable for Debian?
Thomas
On 28 October 2012 08:47, Jakub Wilk jw...@debian.org wrote:
I assume that building the binary packages from a single source package
is preferred?
sympy devs reckon we should use the separate release tarballs. Is that
acceptable for Debian?
Yes.
OK. I've committed the minor changes
On 29 October 2012 04:42, Dmitry Shachnev mity...@gmail.com wrote:
What was the MathJax complain about? I maybe can help you with that.
dh_sphinxdoc: debian/python-sympy/usr/share/doc/python-sympy/html/
https://c328740.ssl.cf1.rackcdn.com/mathjax/latest/MathJax.js?config=TeX-AMS_HTML-fullis
(Resending to the list - sorry)
On 6 November 2012 12:36, Thomas Kluyver tho...@kluyver.me.uk wrote:
On 6 November 2012 12:03, Dmitrijs Ledkovs x...@debian.org wrote:
Can you add an autopkgtest that runs the upstream testsuite?
I've had a go - can you have a glance at the attached patch
On 6 November 2012 12:54, Dmitrijs Ledkovs x...@debian.org wrote:
Looks good. Commit and I will sponsor your package.
Done. Thanks, Dmitrijs.
Thomas
On 6 November 2012 13:18, Dmitrijs Ledkovs x...@debian.org wrote:
I am thinking to upload to experimental instead of unstable. It's a
few upstream releases jump and a python3 package is introduced.
This makes this changes unsuitable for unstable considering that we
are currently frozen and
On 8 November 2012 14:15, Andreas Tille andr...@an3as.eu wrote:
As far as I have followed this thread I have not seen an answer to this
part of your mail. I admit I have no idea how to support Python 2 *and*
3 but wild-guessing from my experience with Debian tools I doubt any
manual code
This is an idea I've had knocking around for a while. Packaging is complex
- there are lots of different tools and syntaxes you have to understand to
do a good job of it - quilt, debhelper, watch files, etc. - along with
specialist terminology. I know various CLI tools aim to simplify things,
but
On 9 November 2012 12:44, Maykel Moya mm...@mmoya.org wrote:
Even in the case of the more restrictive license applying only to
debian/* work? Could you/someone elaborate a little the implications of
this (link to fine documentation is welcomed)?
I'm not sure if there's a Debian rule about
Returning to the original topic: I've now svn-injected python3-sympy [1],
and successfully built it in a PPA [2].
[1] http://anonscm.debian.org/viewvc/python-modules/packages/python3-sympy/
[2] https://launchpad.net/~takluyver/+archive/python3
Thanks,
Thomas
On 8 November 2012 13:32, Jakub
(Resending to the list)
Hi Philippe,
On 13 November 2012 12:36, Philippe Makowski pmakow...@espelida.com wrote:
I never packaged any thing for Debian yet, I have to learn everything
about Debian rules and tools for packaging.
I'm trying to start a GUI application to simplify Debian
On 14 November 2012 11:43, Jakub Wilk jw...@debian.org wrote:
I don't think so, sorry.
Could you expand on this at all? Do you think that packaging should be left
to the experts? Or that the existing systems are easy enough for newcomers
to learn?
Thomas
Hi Clint,
On 15 November 2012 03:53, Clint Byrum cl...@ubuntu.com wrote:
https://launchpad.net/pkgme
At one point I was interested in writing a ruby backend for this, but
got distracted and moved to other focus, but I think it solves what you
are talking about, without need to develop a
On 15 November 2012 15:18, Andrey Rahmatullin w...@wrar.name wrote:
Bottom line: if you want to get a good package, it's not always possible
to fully automate that, especially in cases of complex (and proprietary)
software like that you mentioned, and so a GUI wizard can't do everything
On 22 December 2012 22:00, Bas Wijnen wij...@debian.org wrote:
6. Make /usr/bin/program a symlink to the actual file in the private
directory. It will then search in its real place. (I've seen this used
by angrydd.)
This (symlinking /usr/bin/program) appears to be the recommended way to
deal
The python-xlrd package is maintained by Thomas Bläsing and the DPMT, but
the packaged version is quite old. A PAPT thread from last year suggests
that Thomas Bläsing is missing in action [1].
I've prepared a new version of the package, using a patch from the bug
tracker, the latest upstream
On 6 February 2013 12:52, Sandro Tosi sandro.t...@gmail.com wrote:
Yes I do: Thomas is set as the Maintainer (as opposed to the team
being the Maintainer), so your are more forced to ask Thomas first
given the huge changes you're planning to do: did you contact him (it
doesn't seem so from
On 6 February 2013 19:30, Sandro Tosi sandro.t...@gmail.com wrote:
please read our unwritten policy about Maintainer field at
http://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin
As a general rule of thumb, just set Maintainer to the team; there might
be some exceptions, like in
On 14 February 2013 16:41, Sandro Tosi sandro.t...@gmail.com wrote:
so please search into the mailing list archive about the several
iterations of such discussion and the outcome of them.
The most recent discussion I found with a quick search started nearly 2
years ago. Nobody appeared to be
On 14 February 2013 20:29, Barry Warsaw ba...@python.org wrote:
I look at the switch to dh_python2 as an example.
I don't think it's a particularly good example, though. Lots of packages
continue to use the older helpers, and not due to a lack of time - attempts
to move away from the
On 14 February 2013 22:54, Matthias Klose d...@debian.org wrote:
That causes problems when newcomers don't want to learn
deprecated packaging methods, and aren't allowed to update packages to
use
the recommended helper.
Agreed, so why not helping with it? Again, why not helping here?
On 16 February 2013 09:10, Thomas Goirand z...@debian.org wrote:
It would be really stupid to only want to claim to be working as part
of the team, that's not at all what I want to do. I'd like to be able to
help when I can, and receive help when I need, which is the point of a
team.
I
On 18 February 2013 20:46, Ludovic Gasc gml...@gmail.com wrote:
I vote D, and I can handle the migration from SVN to Git, I've done this
several times for my work and WYMeditor.
Are you interested?
I'm interested personally, but the votes so far suggest there's no real
will for any change -
On 18 February 2013 22:23, Ludovic Gasc gml...@gmail.com wrote:
I propose to make a poll on the Web (Doodle or other) and ask the question
in another thread, I'm not sure that each subscriber has read this long
thread.
I don't think I'll do that myself - the responses I have seen don't have
On 19 February 2013 17:55, Thomas Goirand z...@debian.org wrote:
Thomas Kluyver
Seems to be ok with migrating to Git (so, option D)
I voted CDBA in the same e-mail that I introduced the poll ;-). Thanks for
summarising the votes.
Including Piotr Andreas, and putting people whose opinion
On 20 February 2013 14:38, Olе Streicher debian-de...@liska.ath.cx wrote:
I am trying to create packages for Python3 for the source package
[1]. Following the guide [2], I get some success. However, the packages
for Python2 and Python3 differ significantly: in the Python2 package,
all machine
On 20 February 2013 14:53, Thomas Goirand z...@debian.org wrote:
In what way the QA is different because it's a tag instead of a tarball ?
I don't understand your reasoning. In both cases, you must make sure
that what you are packaging is buildable, tested, QA, etc.
I think the idea is that,
On 22 February 2013 06:28, Dmitry Shachnev mity...@gmail.com wrote:
After looking at all packages that build-depend on python3-nose, I've
identified these packages as needing fix:
I happen to recall that python-xdg is also affected, both in debian/rules
[1] and autopkgtests [2].
I'm happy to
On 14 March 2013 14:01, Scott Kitterman deb...@kitterman.com wrote:
3. Don't care to invest any thought or time in the question.
That's pretty much my thinking.
If someone wants to go through and automatically change svn. - anonscm.,
that's fine. I'm mildly against having a Lintian rule for
On 7 May 2013 18:46, Sandro Tosi sandro.t...@gmail.com wrote:
debian-python doesn't deserve a similar communication (don't you dare
thinking about coordination, it's out of question) because we're just
a bunch of puppets waiting for orders by the ultimate master - well
done.
Selectively
Please can someone upload the new package python3-sympy
Package name : python3-sympy
Version : 0.7.2-2
URL : http://sympy.org/
Binary packages: python3-sympy
It's already in the team svn:
svn://svn.debian.org/python-modules/packages/python3-sympy/trunk/
From a previous
On 19 June 2013 05:47, Brian May br...@microcomaustralia.com.au wrote:
How do I do this? I don't see any references to objects.inv in the
upstream source code for django-filter, and I am not really sure what these
files are used for.
The files are an index of objects described in the Python
On 22 May 2013 16:28, Barry Warsaw ba...@python.org wrote:
I think we should consider switching back to setuptools once 0.7 is
released
(defined as available on PyPI), since this will clearly be the future of
this
component. We may have some fallout to deal with in other packages
(e.g.
On 6 June 2013 11:15, Thomas Kluyver tak...@gmail.com wrote:
Please can someone upload the new package python3-sympy
Package name : python3-sympy
Version : 0.7.2-2
URL : http://sympy.org/
Binary packages: python3-sympy
It's already in the team svn:
svn
On 3 July 2013 19:36, Barry Warsaw ba...@debian.org wrote:
The reason is that if some code is trying to:
except 'error message'
this will fail if the raise site is changed.
In fact it will already fail - recent Python 2 versions throw a TypeError
if you attempt to raise a bare string
On 16 July 2013 22:25, Stéphane Blondon stephane.blon...@gmail.com wrote:
I checked the string exceptions in the code and they are not catched
(see shell commands used at this end of this message).
So I plan to wrap the string with an exception (Exception ou
TypeError). To me, the errors
I've updated the python3-sympy package in SVN to the new upstream release,
0.7.3. Is anyone interested in reviewing or uploading this?
Thank-you,
Thomas
On 29 June 2013 23:17, Thomas Kluyver tak...@gmail.com wrote:
On 6 June 2013 11:15, Thomas Kluyver tak...@gmail.com wrote:
Please can
On 18 September 2013 08:41, Piotr Ożarowski pi...@debian.org wrote:
so instead of reinventing the wheel and trying to make something that
works everywhere they should make it easier for others to convert
whatever they provide (tarballs?) into .rpm, .deb or .exe.
From a developer point of
On 20 September 2013 01:11, Thomas Goirand z...@debian.org wrote:
From a developer point of view: this leaves you dependent on other
people to get the latest release of your software to users, which can be
very frustrating. For instance, I'm a developer for IPython: we made a
1.0 release
On 20 September 2013 10:52, Paul Tagliamonte paul...@debian.org wrote:
If a library breaks API because the maintainer wanted another toy
rewrite, we're not going to upload it and break half the archive. That's
silly.
This condescending attitude towards developers ('another toy rewrite')
On 20 September 2013 12:08, Paul Tagliamonte paul...@debian.org wrote:
Don't take this as me trashing on Python or Pythonistas. If you want to
talk
about this in person, I'm usually at PyCon. I'm also usually in the
packaging
BOF. Perhaps we can bring some of this up there this year?
On 20 September 2013 16:00, Andrey Rahmatullin w...@wrar.name wrote:
Packaging often takes much longer than a couple of days, especially if the
packager is not experienced. And when the work is published somewhere, but
not yet uploaded, there is no general way to know if it's published and
Hi Jean-Christophe,
On 29 September 2013 13:31, Jean-Christophe Jaskula
jean.christophe.jask...@gmail.com wrote:
The Ipython team has released a couple of major releases during the last
months but I haven't seen any discussions about packaging them in debian.
Just for curiosity, I decided to
On 11 November 2013 08:45, Barry Warsaw ba...@debian.org wrote:
* Expose /usr/bin/foo with a shebang line of #!/usr/bin/python
* Expose /usr/bin/foo-3 with a shebang line of #!/usr/bin/python3
In upstream IPython, we now install an ipython2 script on Python 2,
paralleling the ipython3
On 25 Jan 2014 07:37, Thomas Goirand z...@debian.org wrote:
On 01/25/2014 06:01 PM, Sandro Tosi wrote:
Sorry, what? and you didn't think to contact me first to almost
rewrite the package? If there's problems, open bugs. Revert your
changes or I'll do at the first occasion. and mainly, why
On 26 Jan 2014 16:33, Paul Tagliamonte paul...@debian.org wrote:
On Mon, Jan 27, 2014 at 12:14:12AM +0100, Nicolas Dandrimont wrote:
[ awesome points here ]
Cheers,
Nicolas Dandrimont
Hear, Hear!
Ditto - I agree with just about everything Nicolas said. I'd love to see
this become a
On 7 May 2014 14:11, Paul Tagliamonte paul...@ubuntu.com wrote:
If I had more time to blow, I'd likely try a run at something SUDS API
compatible in Python 3. Won't happen any time soon for me, but it's
something I will eternally praise someone over.
So many people have tried to forward-port
On 4 August 2014 10:29, Thomas Goirand z...@debian.org wrote:
Also, fixing version 3 of beautifulsoup doesn't look very easy. It needs
sgmllib, which is removed from Python 3, and it doesn't feel right to
maintain sgmllib as a Python module for Python 3 (I tried, and with a
few hacks, it
On 14 December 2014 at 15:34, Brian May br...@microcomaustralia.com.au
wrote:
Not sure calling it multiple distinct Python packages is correct,
currently there is only one setup.py, and hence only one egg file produced.
e.g. package contains
setup.py
module1/__init__.py
On 11 February 2015 at 14:22, Scott Kitterman deb...@kitterman.com wrote:
Given the filename, shouldn't it be import khmermodule?
foomodule.so was a valid filename for a module 'foo' - though I only heard
about this when that spelling was removed in Python 3.3:
On 14 April 2015 at 08:10, Barry Warsaw ba...@python.org wrote:
But it fails unhelpfully when you use it in a shebang.
$ /tmp/foo.py
bash: /tmp/foo.py: /usr/bin/python: bad interpreter: No such file or
directory
Let's make the latter more helpful.
From a script authors point of view,
On 21 April 2015 at 08:15, Barry Warsaw ba...@debian.org wrote:
For third parties who want to distribute scripts that run out-of-the-box
everywhere (installers, cross-platform system management or monitoring
scripts, build scripts, etc.), Python 3 isn't an option. If we remove
Python
2 from
It's worth mentioning that in virtualenvs and conda envs, where there can
only be one version of Python installed, 'python' refers to that whether it
is Python 3 or 2. So it's already not a safe assumption that 'python'
always means Python 2, even if you discount Arch.
On 15 April 2015 at 21:04,
On 14 April 2015 at 08:57, Scott Kitterman deb...@kitterman.com wrote:
I have scripts I use locally that are untouched in almost a decade that use
/usr/bin/python.
I'm thinking about scripts that are written and distributed to people
running on different, unknown, Linux distros. Obviously if
On Mon, Jun 22, 2015, at 12:20 PM, Andreas Tille wrote:
/home/andreas/debian-maintain/alioth/debian-med_git/build-area/python-dendropy-4.0.2/dendropy/utility/textprocessing.py,
line 44, in bytes_to_text
s = codecs.decode(s, ENCODING)
TypeError: must be string, not None
Looks like
On Mon, Aug 24, 2015, at 04:30 PM, Robert Collins wrote:
c) write convoluted tricky code to workaround the bugs and differing
behaviour on 3.4 vs 3.5.
I use unittest.mock from Python 3.4 on several packages, and it has not
required convoluted code. I would be very surprised if that code breaks
1 - 100 of 105 matches
Mail list logo
