Re: [Zope-DB] Pitfall: mxODBCZopeDA and test runner in 2.9+
M.-A. Lemburg wrote: 3. decide it really should have been mybar.py I suppose you are doing 'mv myfoo.py mybar.py' here ... 4. delete myfoo.py ... then this should be 'rm myfoo.py*' to get rid off the old PYC files. Indeed... 5. run unit tests to make sure you've fixed all import statements That's a weird way to check your code. You should really do a grep on the sources to see whether any references to the 'myfoo' module are still left. Nah, that just means you're too lazy to get decent test coverage ;-) code quality or to find hidden imports, unless you have 100% code coverage and are able to test all possible combinations of execution paths, which is unlikely :-) Actually, no. Code coverage by unit tests on projects I work with is pretty high... 7. get errors on fresh checkout because unit tests were using mybar.pyc I still have a feeling that your trying to work around developer laziness here ;-) Agreed. I always use -k to the testrunner, but I'm just explaining why people are having the problems they are... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope-DB mailing list Zope-DB@zope.org http://mail.zope.org/mailman/listinfo/zope-db
Re: [Zope-DB] Pitfall: mxODBCZopeDA and test runner in 2.9+
Chris Withers wrote: > M.-A. Lemburg wrote: >> As I understand it, the only case that the PYC cleaner is trying >> to work around here is a local configuration problem which only >> occurs if some PY file was removed upstream. > > Nope, not at all... > > Quite often shows up early in the development cycle... > > 1. create myfoo.py > > 2. run unit tests > > 3. decide it really should have been mybar.py I suppose you are doing 'mv myfoo.py mybar.py' here ... > 4. delete myfoo.py ... then this should be 'rm myfoo.py*' to get rid off the old PYC files. > 5. run unit tests to make sure you've fixed all import statements That's a weird way to check your code. You should really do a grep on the sources to see whether any references to the 'myfoo' module are still left. Unit tests only make sure that you haven't screwed up some functional part of the machinery. They don't help to verify code quality or to find hidden imports, unless you have 100% code coverage and are able to test all possible combinations of execution paths, which is unlikely :-) PyChecker and grep are much better for this kind of task. > 6. happilly checkin > > 7. get errors on fresh checkout because unit tests were using mybar.pyc I still have a feeling that your trying to work around developer laziness here ;-) That's not a bad thing in general, but if this causes unwanted side-effects for other people, you should really think twice before adding a change that saves you 10 minutes every now and then while causing many others to spend 30 minutes or more trying to figure out why their code doesn't work anymore after a simple test run... -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 19 2006) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Zope-DB mailing list Zope-DB@zope.org http://mail.zope.org/mailman/listinfo/zope-db
Re: [Zope-DB] Pitfall: mxODBCZopeDA and test runner in 2.9+
M.-A. Lemburg wrote: As I understand it, the only case that the PYC cleaner is trying to work around here is a local configuration problem which only occurs if some PY file was removed upstream. Nope, not at all... Quite often shows up early in the development cycle... 1. create myfoo.py 2. run unit tests 3. decide it really should have been mybar.py 4. delete myfoo.py 5. run unit tests to make sure you've fixed all import statements 6. happilly checkin 7. get errors on fresh checkout because unit tests were using mybar.pyc cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope-DB mailing list Zope-DB@zope.org http://mail.zope.org/mailman/listinfo/zope-db
Re: [Zope-DB] Pitfall: mxODBCZopeDA and test runner in 2.9+
Dieter Maurer wrote: > M.-A. Lemburg wrote at 2006-10-18 12:02 +0200: >> ... >> As I understand it, the only case that the PYC cleaner is trying >> to work around here is a local configuration problem which only >> occurs if some PY file was removed upstream. >> >> In such a case, checking in the PYC files seems like the >> proper fix, since then Subversion or CVS will automatically >> and correctly remove the PYC file as well. > > We should not manage "*.pyc" file in the repository: they > carry the source path as of their creation -- which is likely to be wrong for > the working directory. This makes tracebacks and debugging much more > difficult We've been using such a setup for years and have never run into any serious problems with the traceback sometimes mentioning source file paths don't exist on the target machine. BTW: I was talking about a setup where the developer puts the code under version control. I'm not suggesting to do this for the Zope repository (or any other upstream repository). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 18 2006) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Zope-DB mailing list Zope-DB@zope.org http://mail.zope.org/mailman/listinfo/zope-db
Re: [Zope-DB] Pitfall: mxODBCZopeDA and test runner in 2.9+
M.-A. Lemburg wrote at 2006-10-18 12:02 +0200: > ... >As I understand it, the only case that the PYC cleaner is trying >to work around here is a local configuration problem which only >occurs if some PY file was removed upstream. > >In such a case, checking in the PYC files seems like the >proper fix, since then Subversion or CVS will automatically >and correctly remove the PYC file as well. We should not manage "*.pyc" file in the repository: they carry the source path as of their creation -- which is likely to be wrong for the working directory. This makes tracebacks and debugging much more difficult -- Dieter ___ Zope-DB mailing list Zope-DB@zope.org http://mail.zope.org/mailman/listinfo/zope-db
Re: [Zope-DB] Pitfall: mxODBCZopeDA and test runner in 2.9+
On Wed, Oct 18, 2006 at 09:34:26AM +0200, M.-A. Lemburg wrote: > Looks like the testrunner implementation doing the PYC "cleanup" > is seriously broken. > > At the very least it should: > > * check for the existence of a corresponding PY file before >simply going about removing the byte code file Sorry, but that's exactly backwards of the use case. Read the thread again. > * ignore any permission errors it finds That might be a good idea. -- Paul Winkler http://www.slinkp.com ___ Zope-DB mailing list Zope-DB@zope.org http://mail.zope.org/mailman/listinfo/zope-db
Re: [Zope-DB] Pitfall: mxODBCZopeDA and test runner in 2.9+
Chris Withers wrote: > M.-A. Lemburg wrote: >> Looks like the testrunner implementation doing the PYC "cleanup" >> is seriously broken. >> >> At the very least it should: >> >> * check for the existence of a corresponding PY file before >>simply going about removing the byte code file > > Urm, since it was added specifically to remove rogue pyc files that have > no matching py file, this won't help ;-) As I understand it, the only case that the PYC cleaner is trying to work around here is a local configuration problem which only occurs if some PY file was removed upstream. In such a case, checking in the PYC files seems like the proper fix, since then Subversion or CVS will automatically and correctly remove the PYC file as well. If that doesn't prove to be workable, perhaps there's some way to teach Subversion to run a hook script locally that takes care of removing auxiliary files created by the running process (not only PYC files). Anyway, I've already posted a script to create PY files from PYC files, so we have a work-around for the broken testrunner :-) >> * ignore any permission errors it finds > > Agreed :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 18 2006) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Zope-DB mailing list Zope-DB@zope.org http://mail.zope.org/mailman/listinfo/zope-db
Re: [Zope-DB] Pitfall: mxODBCZopeDA and test runner in 2.9+
M.-A. Lemburg wrote: Looks like the testrunner implementation doing the PYC "cleanup" is seriously broken. At the very least it should: * check for the existence of a corresponding PY file before simply going about removing the byte code file Urm, since it was added specifically to remove rogue pyc files that have no matching py file, this won't help ;-) * ignore any permission errors it finds Agreed :-) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope-DB mailing list Zope-DB@zope.org http://mail.zope.org/mailman/listinfo/zope-db
Re: [Zope-DB] Pitfall: mxODBCZopeDA and test runner in 2.9+
Paul Winkler wrote: > On Fri, Oct 13, 2006 at 12:46:27PM +0200, M.-A. Lemburg wrote: >> Sounds like a developer setup :-) >> >> For those I do have a solution: >> >> chown root.zope .../Products/mxODBCZopeDA >> chmod 750 .../Products/mxODBCZopeDA >> >> (provided zope is the group of the Zope daemon) >> >> That way you prevent deletions in the product directory >> by any user other than root. > > Yes, Tres suggested that on another list. But doing this also > prevents the test runner from running any tests :-) > It bails out with errors like: > > Traceback (most recent call last): > (snip) > File > "/home/pw/rhg/code/contentservices_dev/opt/Zope-2.9.1/lib/python/zope/testing/testrunner.py", > line 1116, in remove_stale_bytecode > os.unlink(fullname) > OSError: [Errno 13] Permission denied: > '/home/pw/dev/instances/zope/lib/python/mx/ODBC/__init__.pyc' Looks like the testrunner implementation doing the PYC "cleanup" is seriously broken. At the very least it should: * check for the existence of a corresponding PY file before simply going about removing the byte code file * ignore any permission errors it finds BTW, it is not uncommon to put PYC files under version control as well, namely in the case where you don't regularly switch Python versions and for files which you normally don't touch, so as the Python std lib modules. In such a case the "byte-code-remover" will cause you serious problems the other way around: because the byte code contains a timestamp, the PYC files will change with every recreation and thus Subversion or CVS will want to check in these changes every time you try to fix a bug... IMHO, it should be an option to remove the PYC files and not the default. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 18 2006) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Zope-DB mailing list Zope-DB@zope.org http://mail.zope.org/mailman/listinfo/zope-db
Re: [Zope-DB] Pitfall: mxODBCZopeDA and test runner in 2.9+
Am 16.10.2006, 15:10 Uhr, schrieb Chris Withers <[EMAIL PROTECTED]>: Charlie Clark wrote: Technically you should actually use $INSTANCE_HOME/modules at least for Never heard of 'modules' before, where did you read about this? My bad - I'm sure I saw it on one of the more recent Zope versions but you're right ../lib/python is the right target for packages. newer versions of Zope and I think this is also the way to go in the future. We've stuck with $INSTANCE_HOME/lib as this works with so many different versions of Zope which we try and support - helping users install mxODBC correctly is the number one support issue. Then give them a normal source install (and it's $INSTANCE_HOME/lib/python ...) Sorry, but that wouldn't help the users I'm talking about! Charlie -- Charlie Clark eGenix.com Professional Python Services directly from the Source Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows, Mac OS, Linux, Solaris, FreeBSD for free! ___ Zope-DB mailing list Zope-DB@zope.org http://mail.zope.org/mailman/listinfo/zope-db
Re: [Zope-DB] Pitfall: mxODBCZopeDA and test runner in 2.9+
Charlie Clark wrote: Technically you should actually use $INSTANCE_HOME/modules at least for Never heard of 'modules' before, where did you read about this? newer versions of Zope and I think this is also the way to go in the future. We've stuck with $INSTANCE_HOME/lib as this works with so many different versions of Zope which we try and support - helping users install mxODBC correctly is the number one support issue. Then give them a normal source install ;-) (and it's $INSTANCE_HOME/lib/python ...) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope-DB mailing list Zope-DB@zope.org http://mail.zope.org/mailman/listinfo/zope-db
Re: [Zope-DB] Pitfall: mxODBCZopeDA and test runner in 2.9+
M.-A. Lemburg wrote: > Chris Withers wrote: >> M.-A. Lemburg wrote: If you fail to use -k, the zope test runner will delete bytecode for all your products - including mxODBCZopeDA, which has no .py files to fall back on. Ouch. I'll investigate further - there might be a bug to file against zope.testing. >>> Why does the test runner delete .pyc files in directories it >>> doesn't own ? >> The common case used to be: >> >> 1. run tests in a checkout (generates .pyc's for each .py file imported) >> >> 2. svn up, which deletes a load of .py files >> >> 3. re-run tests, curse and swear that there are still .pyc files lying >>around that got imported, and you only noticed when your production >>environment broke, because you rebuild that out from scratch on >>upgrade >> >> ...so the "autho-pyc-destructor" was built ;-) > > Sounds like a developer setup :-) > > For those I do have a solution: > > chown root.zope .../Products/mxODBCZopeDA > chmod 750 .../Products/mxODBCZopeDA > > (provided zope is the group of the Zope daemon) > > That way you prevent deletions in the product directory > by any user other than root. Here's another way: Using http://www.egenix.com/files/python/pyc2py.py you can convert any .pyc file into a .py file which will import just like the .pyc file. The script also supports glob patterns, so you can do: pyc2py.py *.pyc Imports will run a tad slower, but that shouldn't matter for an application server like Zope. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 13 2006) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Zope-DB mailing list Zope-DB@zope.org http://mail.zope.org/mailman/listinfo/zope-db
Re: [Zope-DB] Pitfall: mxODBCZopeDA and test runner in 2.9+
Am 13.10.2006, 15:43 Uhr, schrieb Paul Winkler <[EMAIL PROTECTED]>: think for my use case, your workaround of putting mxODBCZopeDA under SoftwareHome is probably the best. I'm currently using the test -k flag to prevent bytecode deletion, but it's only a matter of time before that causes me pain of the sort Chris described. I'll put the mx libs in my python site-packages too (since the testrunner also deletes bytecode in $INSTANCE_HOME/lib/python). Technically you should actually use $INSTANCE_HOME/modules at least for newer versions of Zope and I think this is also the way to go in the future. We've stuck with $INSTANCE_HOME/lib as this works with so many different versions of Zope which we try and support - helping users install mxODBC correctly is the number one support issue. Shouldn't be a problem for licensing since our buildout system creates a dedicated "private" python installation; we're not currently sharing python or SOFTWARE_HOME across multiple instances, and I doubt we'll start doing that because it'd take some hacking on the build scripts so it's much cheaper to just keep wasting disk space. Sounds reasonable. Charlie -- Charlie Clark eGenix.com Tel: +49-211-600-3657 GSM: +49-178-782-6226 Professional Python Services directly from the Source ___ Zope-DB mailing list Zope-DB@zope.org http://mail.zope.org/mailman/listinfo/zope-db
Re: [Zope-DB] Pitfall: mxODBCZopeDA and test runner in 2.9+
On Fri, Oct 13, 2006 at 12:46:27PM +0200, M.-A. Lemburg wrote: > Sounds like a developer setup :-) > > For those I do have a solution: > > chown root.zope .../Products/mxODBCZopeDA > chmod 750 .../Products/mxODBCZopeDA > > (provided zope is the group of the Zope daemon) > > That way you prevent deletions in the product directory > by any user other than root. Yes, Tres suggested that on another list. But doing this also prevents the test runner from running any tests :-) It bails out with errors like: Traceback (most recent call last): (snip) File "/home/pw/rhg/code/contentservices_dev/opt/Zope-2.9.1/lib/python/zope/testing/testrunner.py", line 1116, in remove_stale_bytecode os.unlink(fullname) OSError: [Errno 13] Permission denied: '/home/pw/dev/instances/zope/lib/python/mx/ODBC/__init__.pyc' I think for my use case, your workaround of putting mxODBCZopeDA under SoftwareHome is probably the best. I'm currently using the test -k flag to prevent bytecode deletion, but it's only a matter of time before that causes me pain of the sort Chris described. I'll put the mx libs in my python site-packages too (since the testrunner also deletes bytecode in $INSTANCE_HOME/lib/python). Shouldn't be a problem for licensing since our buildout system creates a dedicated "private" python installation; we're not currently sharing python or SOFTWARE_HOME across multiple instances, and I doubt we'll start doing that because it'd take some hacking on the build scripts so it's much cheaper to just keep wasting disk space. Thanks for the input everybody, -- Paul Winkler http://www.slinkp.com ___ Zope-DB mailing list Zope-DB@zope.org http://mail.zope.org/mailman/listinfo/zope-db
Re: [Zope-DB] Pitfall: mxODBCZopeDA and test runner in 2.9+
On Thu, Oct 12, 2006 at 11:57:32PM +0200, Charlie Clark wrote: > For development purposes of this nature you might drop mxODBCZopeDA in > your SOFTWARE_HOME rather than INSTANCE_HOME which should protect. > Charlie Thanks for the suggestion. For those interested, see the current thread on zope3-dev for why this testrunner behavior is a feature, not a bug. -- Paul Winkler http://www.slinkp.com ___ Zope-DB mailing list Zope-DB@zope.org http://mail.zope.org/mailman/listinfo/zope-db
Re: [Zope-DB] Pitfall: mxODBCZopeDA and test runner in 2.9+
Chris Withers wrote: > M.-A. Lemburg wrote: >>> If you fail to use -k, the zope test runner will delete bytecode for all >>> your products - including mxODBCZopeDA, which has no .py files to fall >>> back on. Ouch. I'll investigate further - there might be a bug to file >>> against zope.testing. >> >> Why does the test runner delete .pyc files in directories it >> doesn't own ? > > The common case used to be: > > 1. run tests in a checkout (generates .pyc's for each .py file imported) > > 2. svn up, which deletes a load of .py files > > 3. re-run tests, curse and swear that there are still .pyc files lying >around that got imported, and you only noticed when your production >environment broke, because you rebuild that out from scratch on >upgrade > > ...so the "autho-pyc-destructor" was built ;-) Sounds like a developer setup :-) For those I do have a solution: chown root.zope .../Products/mxODBCZopeDA chmod 750 .../Products/mxODBCZopeDA (provided zope is the group of the Zope daemon) That way you prevent deletions in the product directory by any user other than root. > I have to echo Jens' sentiments though: why not just ship .py files and > be done with it? See my reply to Jens. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 13 2006) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Zope-DB mailing list Zope-DB@zope.org http://mail.zope.org/mailman/listinfo/zope-db
Re: [Zope-DB] Pitfall: mxODBCZopeDA and test runner in 2.9+
On Oct 13, 2006, at 5:14 AM, Chris Withers wrote: I have to echo Jens' sentiments though: why not just ship .py files and be done with it? If I had to make a wild-ass guess, its because there's an indication that the mxodbc code would be misappropriated and proliferated outside of the control of the authors, a circumstance which they desire to avoid. The alternative of shipping .pyc files (and still not letting source out the door) is to spend lots of time coming up with ways to pack source into .pyd files, which would be very clumsy. None of it actually prevents someone who knows the python internals from yanking source (or reconstructed source) back out, but it goes a long way to prevent those folks from saying "oh, well, all software *should* be free -- so I'll just delete this little licensing routine right here *snip* ta-da, I'm pleased to announce free-mxodbc to the world" Actually I don't think anyone would be dumb enough to redistribute misappropriated code, but there ARE a lot of individuals out there whose sense of entitlement exceeds their common sense. I'm sure e- genix would be happy to release the source for a big enough lump sum to pay off their expected future licensing revenue, but in the interim their business model requires people to pay as they go. And since their charges are about the equivalent of a nice night out at an upscale restaurant (or a few passes through McDonalds with a minivan full of kids) I can't see anyone investing the time to write a replacement. ___ Zope-DB mailing list Zope-DB@zope.org http://mail.zope.org/mailman/listinfo/zope-db
Re: [Zope-DB] Pitfall: mxODBCZopeDA and test runner in 2.9+
Jens Vagelpohl wrote: > > On 12 Oct 2006, at 17:57, Charlie Clark wrote: > >>> Am 10.10.2006, 23:35 Uhr, schrieb Paul Winkler <[EMAIL PROTECTED]>: >>> If you fail to use -k, the zope test runner will delete bytecode for all your products - including mxODBCZopeDA, which has no .py files to fall back on. Ouch. I'll investigate further - there might be a bug to file against zope.testing. >>> >>> For development purposes of this nature you might drop mxODBCZopeDA in >>> your SOFTWARE_HOME rather than INSTANCE_HOME which should protect. > > Since I've come against this myself, I'd really like to know a single > sane reason to ship just pyc files. Don't get me wrong, I like the > product and will recommend it all day long, but shipping just pyc files > is odd. Not only gives it a queasy feeling of "well, I guess they really > don't trust their paying customers", it also legally prevents me from > creating patches to help you guys because that would imply I ran one of > the easily-available code decompilers against those Python modules. Even > regardless of the ease with which pyc files can be reconstituted into > readable Python. > > I just couldn't come up with one good reason. Just shipping the .pyc files has a few advantages: * you can be sure that the customer hasn't modified the product and thus support requests are easier to handle * the customer won't run into issues with the .pyc and .py files getting out of sync (e.g. due to permissions of the .py and .pyc files being different), making upgrades a lot easier for the customer OTOH, if you want to help us make the product better, then we should talk :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 13 2006) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Zope-DB mailing list Zope-DB@zope.org http://mail.zope.org/mailman/listinfo/zope-db
Re: [Zope-DB] Pitfall: mxODBCZopeDA and test runner in 2.9+
M.-A. Lemburg wrote: If you fail to use -k, the zope test runner will delete bytecode for all your products - including mxODBCZopeDA, which has no .py files to fall back on. Ouch. I'll investigate further - there might be a bug to file against zope.testing. Why does the test runner delete .pyc files in directories it doesn't own ? The common case used to be: 1. run tests in a checkout (generates .pyc's for each .py file imported) 2. svn up, which deletes a load of .py files 3. re-run tests, curse and swear that there are still .pyc files lying around that got imported, and you only noticed when your production environment broke, because you rebuild that out from scratch on upgrade ...so the "autho-pyc-destructor" was built ;-) I have to echo Jens' sentiments though: why not just ship .py files and be done with it? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope-DB mailing list Zope-DB@zope.org http://mail.zope.org/mailman/listinfo/zope-db
Re: [Zope-DB] Pitfall: mxODBCZopeDA and test runner in 2.9+
Paul Winkler wrote: > If you have mxODBCZopeDA and are using it with zope 2.9 or higher, > a word of warning: > > You *must* use the -k option to the test runner when running > tests in your INSTANCE_HOME. > Example: > > ./bin/zopectl test -k > > If you fail to use -k, the zope test runner will delete bytecode for all > your products - including mxODBCZopeDA, which has no .py files to fall > back on. Ouch. I'll investigate further - there might be a bug to file > against zope.testing. Why does the test runner delete .pyc files in directories it doesn't own ? .pyc files only change if you upgrade to a new Python version, so there doesn't seem to be a need for removing them in the first place. Python is also smart enough to detect updated .py files and regenerate .pyc files from them automatically (.pyc files have a timestamp builtin). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 13 2006) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Zope-DB mailing list Zope-DB@zope.org http://mail.zope.org/mailman/listinfo/zope-db
Re: [Zope-DB] Pitfall: mxODBCZopeDA and test runner in 2.9+
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12 Oct 2006, at 17:57, Charlie Clark wrote: Am 10.10.2006, 23:35 Uhr, schrieb Paul Winkler <[EMAIL PROTECTED]>: If you fail to use -k, the zope test runner will delete bytecode for all your products - including mxODBCZopeDA, which has no .py files to fall back on. Ouch. I'll investigate further - there might be a bug to file against zope.testing. For development purposes of this nature you might drop mxODBCZopeDA in your SOFTWARE_HOME rather than INSTANCE_HOME which should protect. Since I've come against this myself, I'd really like to know a single sane reason to ship just pyc files. Don't get me wrong, I like the product and will recommend it all day long, but shipping just pyc files is odd. Not only gives it a queasy feeling of "well, I guess they really don't trust their paying customers", it also legally prevents me from creating patches to help you guys because that would imply I ran one of the easily-available code decompilers against those Python modules. Even regardless of the ease with which pyc files can be reconstituted into readable Python. I just couldn't come up with one good reason. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFFLtcKRAx5nvEhZLIRAhUVAJ9+0YQ0Y5iG5G7h++9onGBwFHenfACgp6UB DXY4uDHG5BeOiQNjXM86x40= =Mmx4 -END PGP SIGNATURE- ___ Zope-DB mailing list Zope-DB@zope.org http://mail.zope.org/mailman/listinfo/zope-db
Re: [Zope-DB] Pitfall: mxODBCZopeDA and test runner in 2.9+
Am 10.10.2006, 23:35 Uhr, schrieb Paul Winkler <[EMAIL PROTECTED]>: If you have mxODBCZopeDA and are using it with zope 2.9 or higher, a word of warning: You *must* use the -k option to the test runner when running tests in your INSTANCE_HOME. Example: ./bin/zopectl test -k If you fail to use -k, the zope test runner will delete bytecode for all your products - including mxODBCZopeDA, which has no .py files to fall back on. Ouch. I'll investigate further - there might be a bug to file against zope.testing. For development purposes of this nature you might drop mxODBCZopeDA in your SOFTWARE_HOME rather than INSTANCE_HOME which should protect. Charlie -- Charlie Clark eGenix.com Tel: +49-211-600-3657 GSM: +49-178-782-6226 Professional Python Services directly from the Source ___ Zope-DB mailing list Zope-DB@zope.org http://mail.zope.org/mailman/listinfo/zope-db
Re: [Zope-DB] Pitfall: mxODBCZopeDA and test runner in 2.9+
Paul Winkler wrote: If you have mxODBCZopeDA and are using it with zope 2.9 or higher, a word of warning: You *must* use the -k option to the test runner when running tests in your INSTANCE_HOME. Example: ./bin/zopectl test -k But, bear in mind that by doing this, no .pyc's will be deleted meaning you may get weird test behaviour/failure where you've deleted a .py (eg: by an svn up) but forgotten to delete the .pyc... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope-DB mailing list Zope-DB@zope.org http://mail.zope.org/mailman/listinfo/zope-db