Log file Viewer

[00:00:35] <ionelmc> quite odd, pypy3 env is 5 times slower ...

[02:22:26] <Ivo> yo dstufft, if click would be a new virtualenv's only dependency, I think it'd be easier and faster just to write the argparse code out instead, so virtualenv can have 0 dependencies

[02:22:53] <Ivo> and can be installed offline, like pip & setuptools

[02:23:06] <Ivo> or not installed

[02:23:55] <Ivo> would be happy to recode it if you'd like

[21:23:47] <dstufft> bleh

[21:23:49] <dstufft> I hate scripttest

[21:35:04] <ionelmc> dstufft: what's wrong with it?

[21:36:13] <dstufft> ionelmc: I don't have one smoking gun complaint about it, it's just a lot of little API things that I think are bad about it

[21:37:01] <dstufft> and they add up a project I hate using

[21:37:03] <ionelmc> dstufft: it's not worse than the builder api ;)

[21:37:12] <dstufft> what's wrong with the builder API

[21:37:32] <ionelmc> i consider that terrible, having to explicitly pass the damn destination all over the place

[21:38:00] <ionelmc> i can understand having some sort of the similarity with the venv's Builder api but well

[21:38:11] <ionelmc> it doesn't really make sense

[21:38:15] <ionelmc> i don't see any usecase for it

[21:40:41] <ionelmc> dstufft: it also makes the builder hard to extend (if anyone would do that)

[21:40:49] <dstufft> how does it make it hard to extend

[21:42:06] <ionelmc> dstufft: you can't really override a method that doesn't get the dest as an arg, if you want to use the dest in your custom method

[21:42:57] <dstufft> um

[21:43:04] <dstufft> which builder method doesn't get dest as an arg

[21:43:42] <ionelmc> if all the methods get the same dest then it doesn't make sense to pass it explicitly

[21:45:53] <dstufft> it makes complete sense, because a builder is essentially a template for how to create a virtual environment, and the create() method creates it. why should you need to create a new template for every desintation you want to create

[21:46:49] <dstufft> it's conceptually the same as str("I want the virtual environment at {dest}").format(dest="/tmp/env")

[21:48:09] <dstufft> otherwise the builder is just an overcomplicated function, if there's no arguments being passed to the create() function, what's the point of having it be a class with methods at all, you might as well just make a single function create_environment() that takes everything in as arguments

[21:48:33] <ionelmc> dstufft: extensibility of course

[21:48:47] <dstufft> with a function you could just as easily get composability

[21:48:48] <ionelmc> that's why i made the flavors as classes

[21:49:07] <ionelmc> we'll have to see how it plays out with jython and ironpython

[21:49:20] <ionelmc> i have a feeling that terrible things await :-)

[21:50:00] <dstufft> I have a feeling it's going to make more sense to split up LegacyBuilder to a CPythonBuilder, and a PyPyBuilder, and a JythonBuilder, and an IronPythonBuilder

[21:50:28] <ionelmc> dstufft: you can't subclass a module, and i don't like spagetti code (that's what you'd get if you'd want to make 'module with funcitons' extensible)

[21:50:40] <ionelmc> maybe

[21:50:43] <dstufft> ionelmc: composing functions is not spaghetti code

[21:52:11] <ionelmc> dstufft: anyway, does it work as expected on osx?

[21:52:22] <ionelmc> cause i don't have that hardware

[21:53:33] <dstufft> I didn't try it yet, I was reading through it first and then I got distracted by this conversation ;) and soon my groceries will be delivered (should be here in 10 minutes or so) so I'll probably have to go away to take care of that soon

[21:54:37] <ionelmc> dstufft: looks like you enjoy arguing too much ;-)

[21:55:49] <dstufft> I enjoy arguing a lot! Almost always I walk away with a better understanding of either my position or the other person's position, and sometimes I realize my position was wrong too which means I'm extra happy about those arguments

[22:07:03] <ionelmc> hehe

[22:07:45] <ionelmc> well i'm taking a look of the pr again, i'm adding some comments on some of the weird stuff

[22:24:35] <ionelmc> dstufft: so regarding the composing functions argument

[22:25:18] <ionelmc> you agree that what's in site.py, the legacy virtualenv is spaghetti code yes?

[22:25:54] <dstufft> in the rewrite or master branch?

[22:25:57] <ionelmc> they are hard to extend, because of that

[22:26:05] <ionelmc> i mean the old virtualenv

[22:26:32] <ionelmc> hard to extend, hard to understand, hard to fix :)

[22:26:49] <ionelmc> just a bunch of functions that are composing

[22:26:54] <dstufft> yea the old thing was all spaghetti code, but that's less because it was functions and more because it was spaghetti code

[22:26:59] <ionelmc> but the state is not clearly separated, thus the mess

[22:27:05] <dstufft> you can write good code and bad code in both situations

[22:28:29] <ionelmc> ofcourse you can, but with function level modules it's like "you know what, i can't change the api for all the functions here, i'll just store this state here in this module level variable"

[22:28:39] <ionelmc> and that's how we ended up with site.py and virtualenv

[22:29:26] <ionelmc> it's more forgiving with the class, you have a good place to store the state, the instance