Mailing List Archive

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

Am 10.10.2006, 23:35 Uhr, schrieb Paul Winkler <pw_lists@slinkp.com>:

> 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

-----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 <pw_lists@slinkp.com>:
>
>> 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

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

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

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

Jens Vagelpohl wrote:
>
> On 12 Oct 2006, at 17:57, Charlie Clark wrote:
>
>>> Am 10.10.2006, 23:35 Uhr, schrieb Paul Winkler <pw_lists@slinkp.com>:
>>>
>>>> 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

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

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

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

Am 13.10.2006, 15:43 Uhr, schrieb Paul Winkler <pw_lists@slinkp.com>:

> 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

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

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

Am 16.10.2006, 15:10 Uhr, schrieb Chris Withers <chris@simplistix.co.uk>:

> 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

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

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

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

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

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

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

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

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

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