Re: [Distutils] [venv] Re: two questions about virtualenv
On Oct 16, 2009, at 12:25 PM, Brandon Craig Rhodes wrote:
Jannis Leidel <jannis@leidel.info> writes:
That'd be very much appreciated, I'm sure the experience of the distribute people would be helpful, too.
I'm not sure I quite approve of their approach, since it makes installing Distribute under Python 3 take a very long time - which, as a result, currently makes creating a virtualenv under Python 3 take a very long time as well. Someone was complaining to me about that just earlier this week.
Doesn't that also mean that the Python 3 version of Distribute is generated live on the installation system? That doesn't seem right because that leaves the possibility that the code generated by 2to3 is different from the code that passed the (hypothetical, at this point) tests before the distribution was created. I'm going to cross-post this to the distutils list as well. If the idea is to stabilize Distribute, get some tests in place, etc. then this method of distribution (running 2to3 in situ, as it were) is not the correct way to do it from a "shipping the tested product" perspective. S
2009/10/16 ssteinerX@gmail.com <ssteinerx@gmail.com>:
Doesn't that also mean that the Python 3 version of Distribute is generated live on the installation system?
That is absolutely true.
That doesn't seem right because that leaves the possibility that the code generated by 2to3 is different from the code that passed the (hypothetical, at this point) tests before the distribution was created.
The tests are not hypothetical. The code may be different if you use different versions of Python, since they may have different version of the 2to3 library. That is however not a bigger problem than any other incompatibilities between different python versions.
I'm going to cross-post this to the distutils list as well. If the idea is to stabilize Distribute, get some tests in place, etc. then this method of distribution (running 2to3 in situ, as it were) is not the correct way to do it from a "shipping the tested product" perspective.
I don't agree with that statement. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
On Oct 16, 2009, at 12:59 PM, Lennart Regebro wrote:
I'm going to cross-post this to the distutils list as well. If the idea is to stabilize Distribute, get some tests in place, etc. then this method of distribution (running 2to3 in situ, as it were) is not the correct way to do it from a "shipping the tested product" perspective.
I don't agree with that statement.
This is not analogous to running a C compiler, it's analogous to running a pre-processor maybe, but the fact that the distribution doesn't run the tests on the exact code delivered in the package gives me agita. S
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ssteinerX@gmail.com wrote:
On Oct 16, 2009, at 12:59 PM, Lennart Regebro wrote:
I'm going to cross-post this to the distutils list as well. If the idea is to stabilize Distribute, get some tests in place, etc. then this method of distribution (running 2to3 in situ, as it were) is not the correct way to do it from a "shipping the tested product" perspective. I don't agree with that statement.
This is not analogous to running a C compiler, it's analogous to running a pre-processor maybe, but the fact that the distribution doesn't run the tests on the exact code delivered in the package gives me agita.
You can't run tests on an sdist: at a minimus, you have to build it and run the tests with the build directory on your path. Tests run inside a "develop" egg (a VCS checkout) are always potentially influenced by the environment they are run in, which is why we need buildbots (or the equivalent) for each supported platform. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrYtsQACgkQ+gerLs4ltQ51CQCfX6nwpS50Vwj1VVX96eOi7MeR SCEAoIFuefuVRZa9UbyWzU6Q/R2WYBt1 =tdbU -----END PGP SIGNATURE-----
On Oct 16, 2009, at 2:09 PM, Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
ssteinerX@gmail.com wrote:
On Oct 16, 2009, at 12:59 PM, Lennart Regebro wrote:
I'm going to cross-post this to the distutils list as well. If the idea is to stabilize Distribute, get some tests in place, etc. then this method of distribution (running 2to3 in situ, as it were) is not the correct way to do it from a "shipping the tested product" perspective. I don't agree with that statement.
This is not analogous to running a C compiler, it's analogous to running a pre-processor maybe, but the fact that the distribution doesn't run the tests on the exact code delivered in the package gives me agita.
You can't run tests on an sdist: at a minimus, you have to build it and run the tests with the build directory on your path. Tests run inside a "develop" egg (a VCS checkout) are always potentially influenced by the environment they are run in, which is why we need buildbots (or the equivalent) for each supported platform.
Buildbots seem to be in short supply though they should be easy enough to come by in this day and age of penny-an-hour cloud computing. I think I'll see if maybe I can just whip up something about this... S
On 06:33 pm, ssteinerx@gmail.com wrote:
On Oct 16, 2009, at 2:09 PM, Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
ssteinerX@gmail.com wrote:
On Oct 16, 2009, at 12:59 PM, Lennart Regebro wrote:
I'm going to cross-post this to the distutils list as well. If the idea is to stabilize Distribute, get some tests in place, etc. then this method of distribution (running 2to3 in situ, as it were) is not the correct way to do it from a "shipping the tested product" perspective. I don't agree with that statement.
This is not analogous to running a C compiler, it's analogous to running a pre-processor maybe, but the fact that the distribution doesn't run the tests on the exact code delivered in the package gives me agita.
You can't run tests on an sdist: at a minimus, you have to build it and run the tests with the build directory on your path. Tests run inside a "develop" egg (a VCS checkout) are always potentially influenced by the environment they are run in, which is why we need buildbots (or the equivalent) for each supported platform.
Buildbots seem to be in short supply though they should be easy enough to come by in this day and age of penny-an-hour cloud computing.
I think I'll see if maybe I can just whip up something about this...
Not sure if you're aware, but the latest version of buildbot includes support for managing ec2-based slaves. That's an easy way to get all the slaves you can afford. Jean-Paul
On Oct 16, 2009, at 3:56 PM, exarkun@twistedmatrix.com wrote:
Buildbots seem to be in short supply though they should be easy enough to come by in this day and age of penny-an-hour cloud computing.
I think I'll see if maybe I can just whip up something about this...
Not sure if you're aware, but the latest version of buildbot includes support for managing ec2-based slaves. That's an easy way to get all the slaves you can afford.
No, I did not know that, thanks! Thing is, with ec2's high prices, the number of servers I could afford to put up would be pretty limited. I was thinking more along the lines of options at Rackspace and others (@ Rackspace, for example, 1.5 cents/hr for 256MB 10 GB server). Maybe the best thing to do is just extend buildbot to handle other server types where the prices aren't quite so steep. Thanks for the heads up! S
participants (4)
-
exarkun＠twistedmatrix.com -
Lennart Regebro -
ssteinerX＠gmail.com -
Tres Seaver