pmxbot IRC Log Viewer

[00:13:09] <tclugg> The current state of virtualenv/pip/setuptools/tox support for "PEP-0496 - Environment Markers" (https://www.python.org/dev/peps/pep-0496/) is infuriating because various tools don't work like they should. </rant>

[00:22:22] <tclugg> add `wheel` to the above list of suspect packages.

[00:32:01] <zahlman> (I wonder if part of the problem is that setuptools seems designed to wrap distutils, rather than refactor and fix it.)

[02:24:01] <zahlman> Is ez_setup.py still a thing? Can I tell it somehow to determine the latest version of setuptools and grab that, rather than a default specified in the script or something explicitly passed in?

[03:31:59] <tclugg> zahlman: I don't know, except that https://bitbucket.org/pypa/setuptools/raw/bootstrap/ez_setup.py exists and has setuptools version 18.7.1

[03:46:35] <tclugg> ...and of course 18.7.1 is the current version. So the implied answer is yes.

[04:20:52] <zahlman> tclugg: and the second question?

[05:57:21] <ionelmc> zahlman: it's not a thing anymore, if you install the package with pip you are guaranteed to have setuptools already installed

[07:00:39] <tclugg> zahlman and ionelmc: Yes, but not necessarily the version of setuptools you need.

[07:01:20] <tclugg> eg: the current version of virutalenv only ever installs setuptools 0.18.2

[07:04:39] <tclugg> s/0.18.2/18.2/

[07:10:23] <tclugg> question: How do I have setup.py use an external tool (eg: `meteor build ...`) when building binary distributions that should include "compiled" package data?

[07:11:18] <tclugg> I'm trying to remove compiled javascript and CSS from my source repo

[07:11:31] <tdsmith> there's probably advice on using cython that applies here

[07:13:13] <tclugg> tdsmith: thanks, any pointers? I'll start searching regardless...

[07:13:21] <tdsmith> not specifically, sorry

[08:06:13] <ronny> tclugg: ez_setup is a hack that is supposed to be vendored into a sdist

[08:06:51] <ronny> tdsmith: build tool integration of extrenal building is subpar due to the early design mistake of making the actual building part of distutils

[08:16:04] <tclugg> ronny: hi

[08:19:02] <tclugg> ronny: do you have an opinion on this? --> https://dpaste.de/rs2R

[08:20:28] <ronny> tclugg: nope, im not to deep in the topic

[08:20:32] <ronny> also bbl, off to work

[08:21:49] <tclugg> tdsmith: the dpaste URL for above has my solution to including compiled package data.

[08:33:49] <ionelmc> tclugg: custom commands?

[08:34:50] <ionelmc> tclugg: an example (just copies/installs a "special" file): https://github.com/pytest-dev/pytest-cov/blob/master/setup.py

[13:50:20] <zahlman> tclugg: I think I'm going to not bother with ez_setup any more and assume the user will have an acceptably up-to-date setuptools.

[13:50:42] <zahlman> ionelmc: ^

[13:55:14] <ronny> hi jaraco

[13:56:21] <ronny> jaraco: could you perhaps vocie a oppinion on the setup.py install --pip discussion in distutils-sig, i answered rash myself, and would like to see a statement from you

[14:00:52] <jaraco> Hi ronny. I won’t be able to get to that until later this week.

[14:02:46] <ronny> jaraco: i see ^^

[14:02:57] <jaraco> I’ve set something on my calendar to look at it Friday.

[14:03:31] <ronny> wow, calendar for reading mailing lists seems excessive from the outside

[14:03:47] <jaraco> It’s even more excessive from the inside.

[14:04:09] <jaraco> There are outstanding regressions in the latest release of setuptools that need to be addressed.

[14:04:10] <ronny> jaraco: any oppinion on providing a setuptools mode that completely disables easy_install, im considering to try implementation until christmas

[14:04:31] <jaraco> I’d rather see a convergence of easy_install and pip.

[14:04:37] <jaraco> (install)

[14:04:59] <jaraco> Such that both tools provide the same functionality.

[14:05:24] <ronny> jaraco: that seems __hard__ since they work si different

[14:05:44] <jaraco> (which probably means setuptools delegating install to pip, but requires pip to solve the missing use cases)

[14:05:45] <ronny> i'd rather see setuptools easing people to use pip as the dependency manager and setuptools as the setup.py thing

[14:08:52] <ronny> jaraco: ok, i

[14:09:07] <ronny> i'll cross tht off my list then,

[14:39:19] <mgedmin> zc.buildout relies on easy_install and is still pretty popular

[14:39:35] <mgedmin> I suspect zc.buildout is about the only reason why people still use easy_install

[14:39:58] <mgedmin> (just remembered another reason: some PyPI packages have binary eggs/.exe installers, but not wheels)

[14:59:36] <jaraco> I use easy_install mostly because of pip #3.

[14:59:53] <jaraco> I would like to see wheel support in setuptools, then drop support for eggs.

[15:00:14] <jaraco> Lots of steps, though.

[15:07:16] <ronny> jaraco: given the upcoming build tool pep, why not slwly turn easy_install into a opt out until pip can take over setup requires, install requires and actual installation

[15:08:04] <ronny> as for pip #3, its impossible to fix without encapsulated installs or a different develop install mechanism

[15:09:37] <jaraco> I’m not sure - there’s an open discussion in the complementary setuptools ticket that might address it with .nspkg.pth

[15:09:55] <jaraco> But you’re right - encapsulated installs is something that pip doesn’t support very well.

[15:29:51] <ronny> jaraco: pip explicitly killed them, and imho thats a big loss

[15:30:50] <jaraco> A substantial portion of the community concurs, which is why the switch to pip is non-obvious.

[15:31:16] <tos9> what is "encapsulated installs"?

[15:31:23] <tos9> installing somewhere besides site-packages and using .pths?

[15:39:40] <ronny> tos9: egs where never on sys.path by default, you could aways have multiple versions of a package installed and pick a workingset

[15:39:56] <ronny> tos9: prolbme was, that was confusing, hard, and then the pth hack was on top

[15:40:10] <ronny> additionally it was only suitable for application servers due to startup time

[15:40:33] <ronny> (having 300 zip files on sys.path is a hazard for the import system)

[15:45:10] <tos9> I see.

[20:30:26] <zahlman> I have a setup.py that extends setuptools.command.install to do extra configuration work after the basic installation, interactively. When it calls `input` (3.x), it waits for input, but the prompt message doesn't appear until after the user hits enter. Do I just hack around this?

[20:55:04] <agronholm> zahlman: pip may be redirecting the output -- the install command wasn't made to be abused like this

[21:18:39] <zahlman> :(

[22:16:26] <tclugg> Is it fair to say the dependency chain for pypa related packages is "virtualenv" -> "pip" -> "setuptools" -> "distutils" ?

[22:18:46] <tclugg> (I am aware that virtualenv isn't a pypa maintained package, but it's highly relevant in this context)

[22:19:15] <ionelmc> tclugg: it is owned by pypa

[22:19:21] <ionelmc> just not well maintained :)

[22:19:43] <tclugg> Even the bugs on github need triaging, so many dupes...

[22:20:23] <ionelmc> it's broken beyond repair

[22:20:32] <ionelmc> that's why the rewrite is so interesting

[22:20:42] <tclugg> regardless, does that dependency chain look OK?

[22:21:21] <tclugg> ionelmc: so this rewrite... have you heard of Perl 6?

[22:22:09] <tclugg> The Python community doesn't need "the new hotness" in packaging, it needs bugs to be fixed.

[22:22:12] <ionelmc> tclugg: this https://github.com/ionelmc/virtualenv/

[22:24:50] <tclugg> ionelmc: http://www.joelonsoftware.com/articles/fog0000000069.html

[22:26:25] <ionelmc> tclugg: it's hard to have joel's mindset when you know how broken virtualenv is

[22:28:08] <tclugg> ionelmc: but it *works* for 99% of people, right?

[22:31:31] <tclugg> bbs, going to work.

[22:31:39] <ionelmc> tclugg: you tell me :-)

[22:31:50] <ionelmc> for me it was horrendously broken

[22:32:09] <ionelmc> broken on windows, broken on ubuntu, broken on py3

[22:40:39] <tclugg> ionelmc: I don't disagree with you, it *is* broken in many regards. But it still *works* out there in the real world, installing django + django-rest-framework + ... on millions of servers, every single day.

[22:47:45] <ionelmc> tclugg: there's a reason technical debt is so frequent in the industry ;-)

[23:03:40] <zahlman> ... what are the most obvious/blatant breakages in virtualenv? Now you have me worried...

[23:07:33] <tclugg> zahlman: It installs vendored versions of setuptools, pip, wheel and argparse. A bunch of issues for the default OSX python install. Windows issues. Python 3.5 issues.

[23:08:00] <zahlman> "vendored"?

[23:09:51] <tclugg> zahlman: vendored -- a package included in the source that is maintained by someone else. For virtualenv vendored packages, here is the list: https://github.com/pypa/virtualenv/tree/develop/virtualenv_support

[23:11:05] <zahlman> ah.

[23:11:24] <zahlman> ...wait, isn't `argparse` in the standard library?

[23:16:48] <zahlman> ...since 3.2/2.7 per the doc. so the version in virtualenv is just for backwards compatibility?

[23:17:23] <tclugg> zahlman: probably... *sigh*

[23:18:30] <tclugg> I don't mind it where necessary, but supporting unsupported python releases seems silly.

[23:20:32] <tclugg> I suppose you could argue that LTS versions of RedHat or similar might have old versions of Python, but I'd suggest that would be a problem for the LTS package maintainers -- they're not going to use the latest version of virutalenv by definition, right?

[23:32:07] <ionelmc> tclugg: zahlman: the bundled argparse is not a problem is it? it only gets installed if necessary

[23:35:02] <ionelmc> zahlman: there's some discussion here if you want to know about the "root problems" https://github.com/pypa/virtualenv/pull/697

[23:39:35] <tclugg> ionelmc: that link is *gold*, thanks!

[23:40:17] <ngoldbaum> man, that PR discussion makes me sad. I wonder if there's a way forward there.

[23:44:14] <zahlman> ...wow, and that's from almost a year ago

[23:44:31] <zahlman> what exactly is `click` in this context?

[23:48:41] <ionelmc> zahlman: http://click.pocoo.org/

[23:50:28] <zahlman> ... wow, that looks massively useful for the `cmd` replacement I was working on a few years ago and abandoned...

[23:50:42] <zahlman> very similar design philosophy to what I was doing, even

[23:51:07] <zahlman> (and a lot more fully featured :) )

Log file Viewer

Help | Karma | Search:

#pypa logs for Tuesday the 8th of December, 2015