OoO En cette nuit striée d'éclairs du mercredi 15 juin 2011, vers 02:46,
Jakub Wilk disait :
>> On the debian side I always have to copy-paste the same-looking code
>> over and over again (symlink jquery,
> If you use dh_link in your debian/rules (most likely you do), you need
> only a single li
Yaroslav Halchenko writes:
> On Wed, 15 Jun 2011, Zygmunt Krynicki wrote:
> > Well joke aside you cannot fix the tarball that people release on
> > pypi with half of the test code and data missing just because their
> > MANIFEST.in was flaky.
>
> ;-) And that is when my evil "package from VCS" co
W dniu 15.06.2011 02:46, Jakub Wilk pisze:
* Zygmunt Krynicki , 2011-06-15, 01:03:
In a setup.py world:
$ python setup.py build_sphinx
This is all fine and pretty (thanks to python).
Only if you are happy that your extension modules are built in-place. :/
I did not use extension modules ye
Zygmunt Krynicki writes:
> W dniu 15.06.2011 02:13, Ben Finney pisze:
> >Zygmunt Krynicki writes:
> >> 2) We keep stripping jquery and replacing it with a symlink to
> >> libjs-jquery but we make the process less cumbersome and manual.
Ah, I missed that you were implicitly referring only to Sph
On Wed, 15 Jun 2011, Zygmunt Krynicki wrote:
> >oops -- I bluntly believed that we are taking care about both
> >aspects in Debian ;-)
> Well joke aside you cannot fix the tarball that people release on
> pypi with half of the test code and data missing just because their
> MANIFEST.in was flaky.
W dniu 15.06.2011 02:28, Yaroslav Halchenko pisze:
On Wed, 15 Jun 2011, Zygmunt Krynicki wrote:
That's different. IHMO you ask for make dist-check AFAIR (my
automake-foo is getting old). Testing installed stuff is often
harder and not supported as we don't want to include tests in the
package (
W dniu 15.06.2011 02:13, Ben Finney pisze:
$ python setup.py test
I would also like this to become the de-facto standard. Can we somehow
make it happen? (debian policy, python something?)3.3).
AFAICT it *is* the de facto standard. Perhaps you mean that you want it
to be the de jure standard
* Zygmunt Krynicki , 2011-06-15, 01:03:
In a setup.py world:
$ python setup.py build_sphinx
This is all fine and pretty (thanks to python).
Only if you are happy that your extension modules are built in-place. :/
On the debian side I always have to copy-paste the same-looking code
over and
On Wed, 15 Jun 2011, Zygmunt Krynicki wrote:
> That's different. IHMO you ask for make dist-check AFAIR (my
> automake-foo is getting old). Testing installed stuff is often
> harder and not supported as we don't want to include tests in the
> package (for build-deps vs install-deps). Source layout
Zygmunt Krynicki writes:
> W dniu 15.06.2011 00:04, Barry Warsaw pisze:
> In Python< 3.3, using
> > setuptools/distribute/distutils2, this should be the standard
> > interface:
> >
> > $ python setup.py test
>
> I would also like this to become the de-facto standard. Can we somehow
> make it h
W dniu 15.06.2011 01:06, Yaroslav Halchenko pisze:
ideally I would like to see the helper which would allow (or even by
default would do) to invoke test batteries against just installed (i.e.
python setup.py install) version of the modules: in my experience it
helped to avoid various issues of
W dniu 15.06.2011 00:04, Barry Warsaw pisze:
On Jun 14, 2011, at 05:53 PM, Zygmunt Krynicki wrote:
Can please we have standardized hooks to build sphinx documentation and run
setup.py test tests?
I'd like to see the packaging folks address this. Eric is subscribed to this
list and can probab
ideally I would like to see the helper which would allow (or even by
default would do) to invoke test batteries against just installed (i.e.
python setup.py install) version of the modules: in my experience it
helped to avoid various issues of incomplete inclusion of
submodules/data files.
And s
On Jun 14, 2011, at 12:33 PM, Yaroslav Halchenko wrote:
>ah -- wishlist!
Well, just be careful. :) We have to clearly define what's the responsibility
of upstream Python, what falls under third-party add-ons (e.g. Sphinx), and
what is the integrator/OS-vender's responsibility.
>On Tue, 14 Jun 2
On Jun 14, 2011, at 05:53 PM, Zygmunt Krynicki wrote:
>Can please we have standardized hooks to build sphinx documentation and run
>setup.py test tests?
I'd like to see the packaging folks address this. Eric is subscribed to this
list and can probably speak to packaging's take on it, but my pref
Vincent Bernat writes:
> OoO La nuit ayant déjà recouvert d'encre ce jour du lundi 13 juin 2011,
> vers 23:23, Nikolaus Rath disait :
>
>> Ah, of course. This should be fixed as well now.
>
> OK. Uploaded.
Thanks!
-Nikolaus
--
»Time flies like an arrow, fruit flies like a Banana.«
PGP
OoO La nuit ayant déjà recouvert d'encre ce jour du lundi 13 juin 2011,
vers 23:23, Nikolaus Rath disait :
> Ah, of course. This should be fixed as well now.
OK. Uploaded.
--
Vincent Bernat ☯ http://www.luffy.cx
Indent to show the logical structure of a program.
- The Elements of
ah -- wishlist!
On Tue, 14 Jun 2011, Zygmunt Krynicki wrote:
> Can please we have standardized hooks to build sphinx documentation
> and run setup.py test tests? Can those hooks do the right thing with
> generated documentation (dealing all the boring .doc-base files,
> replacing jquery with symli
W dniu 14.06.2011 16:45, Barry Warsaw pisze:
I want to be a conduit between Debian and upstream, so please, I encourage
everyone who has concrete issues that can help the Debian story, to raise them
here. Python is a big ship so it takes time to steer, but as I hope I've
shown with PEP 3147 and
On Jun 14, 2011, at 03:44 PM, 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
Le 14/06/2011 14:40, Tshepang Lekhonkhobe a écrit :
> Have you guys looked at the new module, Packaging, in Python 3.3? Will
> it solve all the problems that Debian Python packaging has, or is it
> still lacking?
distutils2/packaging is an improved fork of distutils. As such, it will
not revoluti
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
>
On Jun 14, 2011, at 02:40 PM, Tshepang Lekhonkhobe wrote:
>Have you guys looked at the new module, Packaging, in Python 3.3? Will
>it solve all the problems that Debian Python packaging has, or is it
>still lacking?
>
>sidenote: the same tool will be available for earlier Python versions as
>distu
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 lik
Have you guys looked at the new module, Packaging, in Python 3.3? Will
it solve all the problems that Debian Python packaging has, or is it
still lacking?
sidenote: the same tool will be available for earlier Python versions as
distutils2
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.
On Jun 14, 2011, at 07:00 PM, Ben Finney wrote:
>I think (as someone with no special authority on Python nor Debian) that
>the people who know most detail about what's painful for packaging
>Python software for Debian are burned out on the topic. They therefore
>don't want to spend the effort to s
On Tue, 2011-06-14 at 10:09 +0200, Josselin Mouette wrote:
> Overall, as you might have noticed, I have vastly reduced my involvement
> in the Debian Python community. The reason is that all the crap that
> happened in Debian is still a result of broken designs in Python itself.
> I think there is
Barry Warsaw writes:
> On Jun 10, 2011, at 10:02 AM, Paul Wise wrote:
>
> >Personally I've always wondered why a Debian-specific helper should
> >be needed instead of python upstream behaving the way we wanted.
>
> Can you get more specific about this? Obviously, there's little we can
> do about
Le mardi 14 juin 2011 à 09:56 +0200, Stefano Zacchiroli a écrit :
> Joss: can you comment on your stance on deprecating python-support?
> Would you object to that? I know you'd prefer patching upstream Python
> to do the right thing™, but in the meantime converging on a single
> helper might have
On Fri, Jun 10, 2011 at 10:05:16PM +0200, Piotr Ożarowski wrote:
> > What is the process for deprecating python-support? Who makes that
> > decision?
>
> I'd ask Joss, Sandro and Jakub what they think first (if they still
> don't think it's a good idea, it'll never happen)
The choice of technica
30 matches
Mail list logo
