pmxbot IRC Log Viewer

[09:18:31] <Lope> Where should I put get-pip.py script? should I run it as admin?

[09:19:15] <pf_moore> Lope: Anywhere you like, you just run it once and can then delete it

[09:19:56] <pf_moore> Lope: What system are you on? You only need to run it as admin if the Python interpreter you're using to dun it as needs admin privs to install stuff in it

[09:20:26] <pf_moore> Lope: So basically no on Windows, and no on Unix unless you're updating the system, Python which you probably shouldn't do with get-pip

[09:22:35] <Lope> thanks

[13:09:23] <peteretep> CPAN has automated static code quality metrics that run over all distributions and are published; has someone seen anything similar for pypi?

[13:11:15] <doismellburning> peteretep: I would love to see landscape do that (ping carlio)

[13:11:39] <peteretep> doismellburning: What is landscape?

[13:11:51] <doismellburning> peteretep: landscape.io

[13:11:54] <peteretep> thanks

[13:12:13] <peteretep> doismellburning: Ah, that's cool

[13:12:27] <peteretep> doismellburning: CPANTS runs something similar-ish over all of CPAN

[13:12:41] <peteretep> doismellburning: Much less detail, though

[13:16:13] <ionelmc> peteretep: you mean unittests?

[13:16:48] <peteretep> ionelmc: is "unittests" a thing, or do you mean unit tests in general?

[13:17:04] <ionelmc> ok, not unittests

[13:17:12] <ionelmc> "automated testing"

[13:17:17] <peteretep> ionelmc: No, not quite

[13:17:18] <peteretep> http://cpants.cpanauthors.org/author/SARGIE

[13:17:25] <peteretep> That's my CPANTS page for my CPAN modules

[13:17:38] <peteretep> Hover over arrows or crosses, and you can see which metric it's tested

[13:17:50] <ionelmc> aah....

[13:17:56] <ionelmc> no service like that iirc

[13:18:16] <ionelmc> landscape.io is just for actual code, not stuff like packaging practices

[13:18:27] <peteretep> *nod*

[13:18:37] <ionelmc> there are tools to perform some of those checks if you're interested

[13:18:38] <peteretep> There are a few pieces of actual code analysis in those tests too

[13:18:50] <ionelmc> https://pypi.python.org/pypi/pyroma

[13:18:51] <doismellburning> oh it's just for packaging practices? ok

[13:19:06] <peteretep> doismellburning: Many are, but there are things like checking for strict mode and warnings mode

[13:19:12] <doismellburning> (sorry, misunderstood, never actually pushed my own stuff ot CPAN)

[13:19:30] <ionelmc> https://pypi.python.org/pypi/check-manifest

[13:19:33] <peteretep> ionelmc: Oh, that's perfect

[13:19:39] <peteretep> ionelmc: Regarding pyroma

[13:19:42] <ionelmc> and python setup.py check --restructuredtext --strict --metadata

[13:19:44] <peteretep> ionelmc: Thanks

[13:20:39] <ionelmc> peteretep: regardless, i'd go as far as to say that the best practices on packaging are "in flux"

[13:20:48] <ionelmc> doesn't seem to be any consensus

[13:21:20] <mgedmin> TIL about setup.py check

[13:21:21] <ionelmc> and the packaging tools allow lots of crazy stuff due to legacy concerns

[13:21:46] <ionelmc> also, collective.checkdocs

[13:21:57] <ionelmc> https://pypi.python.org/pypi/collective.checkdocs

[13:23:32] <peteretep> In case you're interested, I am wondering about building such a thing for Haskell / Cabal for my MSc

[13:23:39] <Wooble> ionelmc: that's why we need someone very opinionated about what the best practices are to build a site that gives every package a score people can be angry about :)

[13:23:53] <peteretep> Ironic that Python doesn't have that and Perl does ;-)

[13:23:56] <doismellburning> ionelmc: mgedmin: oooh check!

[13:23:57] <peteretep> The opinionated part, that is

[13:24:05] <peteretep> given cultural stereotypes, etc

[13:24:11] <ionelmc> heheh

[13:24:27] <ionelmc> well, I wrote this: http://blog.ionelmc.ro/2014/06/25/python-packaging-pitfalls/

[13:25:04] <ionelmc> no one seemed to notice that 99.99% of the packages on pypi fail those

[13:25:58] <ionelmc> Wooble: imagine the reaction people would have if i'd build a service that scores badly 99.99% of the packages

[13:26:28] <peteretep> ionelmc: It was pretty positive for Perl

[13:26:37] <peteretep> And CPANTS has been a very very positive influence on the CPAN

[13:26:53] <ionelmc> well, i guess we could start with pyroma, it's more lax on the rules

[13:27:02] <peteretep> Perl has Perl::Critic

[13:27:05] <peteretep> which is style and lint stuff

[13:27:09] <peteretep> Which is notably /not/ part of it

[13:27:14] <peteretep> Because no-one can agree on it

[13:27:22] <peteretep> But things like "You need to put a license in"

[13:27:25] <peteretep> Is hard to disagree with

[13:27:35] <Wooble> Yeah, pylint's defaults are fairly widely condemned as well. :)

[13:27:50] <peteretep> For my Hackage one, I am thinking, for example, a score with how many apparent examples you have included

[13:27:57] <peteretep> Do you appear to have documented all your types?

[13:27:57] <peteretep> etc

[13:28:15] <peteretep> Being that it's an MSc project, the plan is to half-write it, write the dissertation, and leave it to fester on GitHub

[13:28:19] <peteretep> but whatever

[13:28:31] <ionelmc> actually, it's a pretty good idea to have such a "critique" service

[13:28:41] <ionelmc> anyone wanna do it?

[13:28:46] <ionelmc> i'm interested

[13:29:43] <peteretep> The gamification effect it creates was non-trivial for CPAN

[13:30:51] <doismellburning> I have just read a client's internal docs for setup.py and they make me weep

[13:33:31] <mgedmin> one day setup.py will be supplanted by something better and everyone'll be happy

[13:33:33] <ionelmc> what could they possibly write there to cause such anguish ?

[13:34:10] <ionelmc> mgedmin: metadata they said, distutils2 they tried

[13:34:18] <peteretep> Perl has gone through about 5 different ones

[13:34:23] <ionelmc> didn't work out

[13:34:24] <peteretep> The most recent ones are JSON based

[13:34:38] <peteretep> And these days you expect the packaging tool to generate the three or four different ones

[13:34:45] <ionelmc> mgedmin: check https://pypi.python.org/pypi/d2to1

[13:34:57] <doismellburning> mgedmin: amen

[13:34:59] <peteretep> Ultimately your packaging data needs to become data, rather than .py

[13:35:00] <mgedmin> yeah, "let's rewrite everything from scratch ignoring backwards compatibility" is not a good approach

[13:35:06] <doismellburning> mgedmin: and again, amen

[13:35:34] <ionelmc> doesn't seem to have much success beyond the openstack packages, that, ironically, are published to pypi with broken or missing metadata

[13:35:38] <peteretep> mgedmin: If you do it right, you generate setup.py from your replacement of it

[13:35:38] <mgedmin> but people who're doing the current packaging push understand that

[13:35:40] <mgedmin> so I have hope

[13:35:45] <mgedmin> it won't be quick, though

[13:35:49] <peteretep> mgedmin: As part of the build process

[13:38:11] <dstufft> distutils2 had the problem whjere it tried to replace the entire toolchain at once

[13:38:28] <dstufft> instead of incrementally adding things to it

[13:41:27] <DanielHolth> IMO the big mistake of distutils2 was trying to replace setuptools by re-standardizing on distutils. Unfortunately distutils is terrible.

[13:42:28] <doismellburning> this setup.py imports from both distutils and setuptools

[13:43:38] <DanielHolth> But they standardized improved metadata. It makes sense to standardize the metadata and the interface to the build system, but it's not a good idea to standardize the build system. Build systems are in general too complicated to be re-implemented compatibly, and the handful-of-C-files extension will always have much different needs than numpy.

[13:47:52] <DanielHolth> Also it is pretty simple to implement enough of the setup.py interface to drive a new build system, if you want.

[13:48:59] <DanielHolth> Main thing lately is that we just don't have a lot of people trying to write better Python build systems.

[13:49:03] <DanielHolth> AFAICT

[13:49:29] <doismellburning> I suspect this might get me kicked, but, er

[13:49:39] <doismellburning> I started trying to make Maven work with PyPI a few years back

[13:50:03] <doismellburning> (well, and virtualenv etc.)

[13:54:01] <ionelmc> dstufft: is there a way to get access to all the package data in a structured way (like json or something, not scraping pypi) ?

[13:54:21] <ionelmc> for statistics purposes

[13:58:56] <dstufft> ionelmc: not really

[13:59:14] <dstufft> well unless you mean what's available on https://pypi.python.org/pypi/<package>/json

[14:04:22] <Wooble> The "local mirroring and caching" link to https://packaging.python.org/en/latest/deployment.html#pypi-mirrors-and-caches (from pypi.python.org/pypi) is broken... that anchor no longer exists on that page.

[14:12:36] <ionelmc> dstufft: anything like that for all the packages ? Just a list of names

[14:17:25] <peteretep> Still think you're better off making setup.py auto-generated from whatever DSL you end up choosing

[14:17:32] <peteretep> that way you have an actual guarantee of backward compatibility

[14:17:42] <peteretep> You can have failed experiments that don't leave too much detritus

[14:17:59] <peteretep> And if your "DSL" is actually just data, you can automatically convert it when the new shiny comes along

[14:32:11] <ionelmc> From my perspective the most jarring thing about distutils2 is the failure to remove the package/module distinction and remove the useless package list. No one needs it, automatic discovery should be the default

[14:35:26] <doismellburning> ionelmc: so, what IS the difference between a package and a module?

[14:36:31] <ionelmc> doismellburning: packages vs py_modules in setup.py

[14:38:05] <dstufft> ionelmc: distutils2 was "let's cram the stuff people put in setup.py in setup.cfg and not really try to advance much beyond that"

[14:38:21] <ionelmc> :(

[14:38:26] <dstufft> it was throwing away most of the ecosystem for little benefit

[14:39:08] <peteretep> doismellburning: A package provides modules

[14:39:12] <peteretep> doismellburning: Did I get it right?

[14:39:22] <doismellburning> peteretep: I have no idea

[14:40:27] <ionelmc> If you wanna distribute just a module you need to use py_mosules

[14:42:30] <ionelmc> Ironically, packages_dir has effects on how py_modules does discovery

[14:43:01] <doismellburning> I am still confused and more sad

[14:47:04] <ionelmc> dstufft: how does the idea of building a package critique service sound ?

[14:47:39] <ionelmc> Like the CPANTS thing

[14:48:34] <ghickman> ionelmc: great article on packaging pitfalls - I think you have a spelling error though

[14:48:36] <ghickman> in "Importing your package in setup.py"

[14:48:52] <ghickman> I think "they might now be available" should be "they might not be available"?

[14:49:01] <ionelmc> Oh yes

[14:49:06] <ionelmc> Thanks

[14:49:44] <ghickman> no problem, thank you for the article!

[14:49:56] <ghickman> especially "Importing your package in setup.py"

[17:32:14] <parkan> I'm getting a weird clang params error when pip installing modules with C extensions, is this the right place to ask about it?

[17:40:00] <Alex_Gaynor> parkan: is it something about "-mno-fused-add" or something like that?

[17:40:58] <parkan> nope, it inserts a {} into the params list, which looks like a failed substitution or something?

[17:40:59] <parkan> https://gist.github.com/parkan/46e9057b49c4c835a148

[18:05:36] <doismellburning> anyone able to point me at good docs on providing integration with `setup.py test`?

[18:06:25] <Yasumoto> doismellburning: not sure if this is quite what you're looking for, but I've had some good luck with tox- https://tox.readthedocs.org/en/latest/

[18:06:48] <doismellburning> Yasumoto: not really, but thanks

[18:07:14] <doismellburning> I have an existing test suite run with `django-admin.py test --settings=wibble`, and I'd like to make that runnable with `setup.py test`

[18:07:37] <doismellburning> (mostly so I can use `test_requires`, and not have to manually install test dependencies beforehand)

[18:09:03] <ionelmc> doismellburning: imho doing custom command stuff in setup.py is just asking for trouble - as that file is run when your package is installed

[18:09:24] <ionelmc> people like to do it, cause it looks convenient

[18:09:35] <ionelmc> but there are no services that use setup.py test

[18:09:59] <ionelmc> and tox is generally better/more flexible

[18:18:32] <DanielHolth> it's also really common to do extras_require : {'test':[test, requires]} then you can install yourpackage[test] and have the test requirements installed.

[18:18:50] <carljm> doismellburning: also, test_requires is just kind of nasty. it dumps the test dependencies right into cwd as eggs

[18:18:59] <carljm> +1 for "just use tox instead"

[18:27:44] <carlio> DanielHolth: oo, i like that idea

[18:39:13] <carlio> does anyone know @pydanny (of django two-scoops fame) enough for an email intro?

[18:41:49] <dstufft> carlio: doismellburning Yasumoto techincally setup.py test and tox serve different purposes, your tox command could run setup.py test

[18:41:52] <dstufft> er

[18:41:54] <dstufft> carljm: ^

[18:49:06] <Yasumoto> dstufft: ah, that's a good distinction

[20:09:31] <carljm> dstufft: Yes, I realize that - but I still think the existence of tox means there aren't very many good reasons to jump through hoops to make setup.py test work.

[20:11:07] <carljm> (a lot of my Django apps actually do support setup.py test, but I wouldn't bother with a new one)

[20:11:40] <carljm> doismellburning: if you do want to make setup.py test, work, here's an example, it's not hard: https://github.com/carljm/django-model-utils/blob/master/setup.py

[20:12:46] <carljm> basically you just have to make a callable that runs the tests, and reference it as dotted path in the test_suite setup kwarg

Log file Viewer

Help | Karma | Search:

#pypa logs for Monday the 6th of October, 2014