Log file Viewer

[09:29:25] <altipard> hi

[09:29:57] <altipard> using zc.recipe.egg, buildout generates a script, wich imports modules before setting the sys.path environment

[09:30:08] <altipard> can i turn this behaviour

[11:18:03] <yota> it's a known issue

[11:18:44] <yota> the pull request is merged I think

[13:55:06] <J1m> altipard, I don't beleave your statement.

[13:55:38] <J1m> yota, are you talking about non-entry-point based scripts?

[13:55:40] <altipard> J1m: you should!

[13:56:21] <altipard> need to look if there is an entry point defined

[13:56:33] <J1m> is this a script defined via entry points? Or via scripts in setup.py?

[13:56:50] <J1m> The latter is very fragile and likely to break.

[13:57:15] <J1m> Basically, without entry points, buildout can't generate a script, it has to hack one.

[16:15:18] <aclark> J1m: is there some element of Buildout's design that dictates the installation of eggs vs just putting modules on sys.path? IOW could Buildout have a "non-egg" mode in which packages were installed in parts/buildout/lib/python (or something like that)?

[16:16:14] <J1m> It *could* would like that, but...

[16:17:09] <J1m> if you wanted to support allowing different scripts to have different deepndency versions, then each script (or each set of scripts output with a given set of dependencies) would need their own lib/python directory.

[16:18:31] <J1m> OTOH, given that most people pin versions at the buildout level, more buildouts use the same versions for all dependencies.

[16:19:40] <J1m> From a theoretical point of view, this would be a big change IMO. The practical effect might be pretty limited though.

[16:20:44] <J1m> If I were going to do this, I'd just give up and have buildout use pip+virtualenv, since they're becoming pretty standard.

[16:21:20] <J1m> Concievably, a buildout could use multiple virtalenvs in the uncommon cases where needed.

[16:21:44] <J1m> Maybe that would be a good idea for buildout3.

[16:23:26] <aclark> J1m: Hmmm, interesting thanks. What about the original design decision to use eggs was that based on anything in particular or just "cool" at the time?

[16:24:12] <J1m> a) trying to follow setuptools b) makes it much easier to support multiple egg versions.

[16:24:26] <J1m> also, makes upgrading downgrading much simpler.

[16:24:33] <aclark> ah

[16:24:34] <aclark> right

[16:24:44] <J1m> I wonder of pip+virtualenv get that right yet.

[16:25:02] <aclark> so the egg format got you some convenience basically

[16:25:02] <J1m> It's actually really hard to get right when everything's mixed together.

[16:25:21] <J1m> The egg format provides a lot of simplicity.

[16:25:45] <aclark> So much Python packaging technology, so little time ;-) (Life is short)

[16:25:52] <J1m> when you mash things together, you have the likely possibility that one package will overwrite files from another.

[16:26:22] <J1m> The egg hate is irrational IMO and going to do a lot of damage.

[16:26:23] <aclark> indeed, good point

[16:26:41] <aclark> I don't hate eggs at all, just trying to understand all the tech

[16:26:59] <J1m> RPMs are a pain in part because of all the expensive gyrations trying to prevent one package from clobbering another package's files.

[16:27:21] <J1m> pip is either going to have to do the same painful thing, or it will get it wrong.

[16:28:32] <J1m> FWIW, in the java ecosystem, things work more like buildout. Sofftware is installed as jars (on which eggs were based) and applications assembled by createing class paths, usually containing lists of jar files.

[16:29:33] <aclark> yep

[16:30:43] <aclark> J1m: Have you looked at wheel AKA "A built-package format for Python." ?

[16:31:14] <J1m> A little and it looks like it's possible to use wheels like eggs.

[16:31:30] <aclark> cool