Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)

2004-04-20 Thread Stephan Richter
On Thursday 15 April 2004 17:11, Martijn Faassen wrote:
  Anyway, I guess the tokenizer is
 fine too, and might even be faster for all I know, just seems an
 unfortunate duplication of work, plus I checked in importchecker for
 little reason. :)

No, Fred was just a bit faster than me with improving finddeps. I think we 
definitely should abstract the import search functionality and put it in a 
lib. The importchecker for example should also look at ZCML to find possible 
usages of imports.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics  Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)

2004-04-15 Thread Jim Fulton
Sidnei da Silva wrote:
On Thu, Apr 15, 2004 at 11:46:27AM +0200, Philipp von Weitershausen wrote:
| - The packages in z can be used for more than just Zope
| 
| +2

So, here's an idea:

 - Move component-architecture packages out of 'zope' into 'ca', and
   then we don't have the 'zope' vs 'Zope' issue anymore.
I've been using stuff from 'zope' (except 'zope.app') for a win32 app *wink*.
Great

So, what about this:

zope.component
zope.interfaces (?)
zope.configuration
zope.testing
zope.schema (soon-to-be-dead?)
- All move to 'ca.*'
Most of this has nothing to do with the component architecture.

ca has nothing to do with zope.

zope.app.*

- Move down to 'zope'.
This doesn't solve name-conflict the problem. Or maybe I don't understand what you
are proposing.
This is pretty rough. Probably there are more stuff that should move
to 'ca', and some stuff which should be grouped into packages, so that
'zope' doesn't get excessively broad.
I think the depth vs breadth balence we have now is about right.

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)

2004-04-15 Thread Sidnei da Silva
On Thu, Apr 15, 2004 at 08:59:44AM -0400, Jim Fulton wrote:
| So, what about this:
| 
| zope.component
| zope.interfaces (?)
| zope.configuration
| zope.testing
| zope.schema (soon-to-be-dead?)
| 
| - All move to 'ca.*'
| 
| Most of this has nothing to do with the component architecture.
| 
| ca has nothing to do with zope.

So that's the intention. If it has nothing to do with zope, why it
should be prefixed with 'zope'? 

I may have been unlucky on trying to enumerate the packages. I was
trying to figure out what kind of stuff would be useful in the context
of zope2. Maybe you can enumerate what packages are part of the
component architecture, and what packages would be used in zope2? I
have a feeling that most stuff in zope.app would not be used in zope2,
but I'm mostly surely wrong.

| zope.app.*
| 
| - Move down to 'zope'.
| 
| This doesn't solve name-conflict the problem. Or maybe I don't understand 
| what you
| are proposing.

See above.

-- 
Sidnei da Silva [EMAIL PROTECTED]
http://awkly.org - dreamcatching :: making your dreams come true
http://plone.org/about/team#dreamcatcher

The most important early product on the way to developing a good product
is an imperfect version.

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)

2004-04-15 Thread Jim Fulton
Sidnei da Silva wrote:
On Thu, Apr 15, 2004 at 08:59:44AM -0400, Jim Fulton wrote:
| So, what about this:
| 
| zope.component
| zope.interfaces (?)
| zope.configuration
| zope.testing
| zope.schema (soon-to-be-dead?)
| 
| - All move to 'ca.*'
| 
| Most of this has nothing to do with the component architecture.
| 
| ca has nothing to do with zope.

So that's the intention. If it has nothing to do with zope, why it
should be prefixed with 'zope'? 
From the zope package README.txt:

  Zope Project Packages

  The zope package is a pure namespace package holding packages developed as
  part of the Zope 3 project.
  Generally, the immediate subpackages of the zope package should be
  useful and usable outside of the Zope application server.  Subpackages
  of the zope package should have minimal interdependencies, although
  most depend on zope.interfaces.
  The one subpackage that's not usable outside the application server is
  the app subpackage, zope.app, which *is* the application
  server. Sub-packages of zope.app are not usable outside of the application
  server. If there's something in zope.app you want to use elsewhere, let us
  know and we can talk about abstracting some of it up out of zope.app.



I may have been unlucky on trying to enumerate the packages. I was
trying to figure out what kind of stuff would be useful in the context
of zope2.
Potentially, all of them.

 Maybe you can enumerate what packages are part of the
component architecture,
zope.component

and what packages would be used in zope2?
All of them, eventually probably including zope.app.

I have a feeling that most stuff in zope.app would not be used in zope2,
but I'm mostly surely wrong.
I think you are probably wrong.

But we don't know for sure yet.

| zope.app.*
| 
| - Move down to 'zope'.
| 
| This doesn't solve name-conflict the problem. Or maybe I don't understand 
| what you
| are proposing.

See above.
I still don't see how having a different package named zope addresses the
name conflict with Zope.
Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)

2004-04-15 Thread Barry Warsaw
On Thu, 2004-04-15 at 09:25, Jim Fulton wrote:

  From the zope package README.txt:
 
Zope Project Packages
 
The zope package is a pure namespace package holding packages developed as
part of the Zope 3 project.
 
Generally, the immediate subpackages of the zope package should be
useful and usable outside of the Zope application server.  Subpackages
of the zope package should have minimal interdependencies, although
most depend on zope.interfaces.

Speaking as someone who's tried to use zope subpackages outside of z3,
there are practical problems with this.  About 8 months ago, I tried to
pull ZPT, et al out to use as a standalone version.  I ended up having
to grab zope.interfaces, zope.pagetemplates, zope.tal, zope.tales, and
zope.i18n.  All make sense (especially since I wanted internationalized
ZPT), but tracking all the dependencies were difficult.  I tried to
update all that again a few weeks ago and found that I also now needed
zope.i18nmessageid and zope.schema.

It looks like Fred's packaging work will help with the very tricky task
of figuring out the dependencies and creating distutils packages for the
desired stuff.  I've also heard that zope.schema is going away and that
the dependency on both zope.i18n and zope.i18nmessageid might not be
necessary.

But I'm still concerned that there will be creeping dependencies among
more things inside the zope package, making it harder to use some of
those technologies independently.  E.g. there are several standalone ZPT
implementations in the wild, but I happen to think z3's is the best and
would like to see it adopted more widely in the Python world.

Also, for a long time I've wanted to see z3's interfaces package be used
outside Zope3, perhaps even being adopted as a standard library package
eventually.  I wonder if living inside the zope container package helps
or hurts those prospects.

I understand the desire to carve out a package namespace that z3 can
reliably use without risk of collision with other packages.  I still
think that's less of a practical concern in the Python world so I'd opt
for an approach that gets the non-Zope specific technologies into the
most hands of Python programmers.

-Barry



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)

2004-04-15 Thread Jim Fulton
Lennart Regebro wrote:
From: Sidnei da Silva [EMAIL PROTECTED]

- Move component-architecture packages out of 'zope' into 'ca', and
  then we don't have the 'zope' vs 'Zope' issue anymore.


'ca' feels weird. Canada? caca? I don't like it. 'z' is better then. Of
course that means that suddenly the component architecture is called z
No, the component architecture is z.component.

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)

2004-04-15 Thread Jim Fulton
Barry Warsaw wrote:
On Thu, 2004-04-15 at 09:25, Jim Fulton wrote:


From the zope package README.txt:

  Zope Project Packages

  The zope package is a pure namespace package holding packages developed as
  part of the Zope 3 project.
  Generally, the immediate subpackages of the zope package should be
  useful and usable outside of the Zope application server.  Subpackages
  of the zope package should have minimal interdependencies, although
  most depend on zope.interfaces.


Speaking as someone who's tried to use zope subpackages outside of z3,
there are practical problems with this.  About 8 months ago, I tried to
pull ZPT, et al out to use as a standalone version.  I ended up having
to grab zope.interfaces, zope.pagetemplates, zope.tal, zope.tales, and
zope.i18n.  All make sense (especially since I wanted internationalized
ZPT), but tracking all the dependencies were difficult.  I tried to
update all that again a few weeks ago and found that I also now needed
zope.i18nmessageid and zope.schema.
It looks like Fred's packaging work will help with the very tricky task
of figuring out the dependencies and creating distutils packages for the
desired stuff. 
Eactly. Freds work is going to adress this problem.
(I'll restrain myself from going into a tirade about how important this
is for Python. :)
I've also heard that zope.schema is going away
I thin it will eventually be merged into zope.interface.

 and that
the dependency on both zope.i18n and zope.i18nmessageid might not be
necessary.
Right, maybe

But I'm still concerned that there will be creeping dependencies among
more things inside the zope package, making it harder to use some of
those technologies independently.  E.g. there are several standalone ZPT
implementations in the wild, but I happen to think z3's is the best and
would like to see it adopted more widely in the Python world.
We're aware of this problem. That's why we've decoded to make the dependency
data explicit (manually created) rather than implicit (automatically created).
Each separately distributed package will have a DEPENDENCIES.cfg that is
created by hand and that *constrains* dependencies on other packages. It
makes explicit the intended dependencies. Dependencies not listed here
are bugs.  Adding depenencies to this file should be considered a big deal.
Also, for a long time I've wanted to see z3's interfaces package be used
outside Zope3, perhaps even being adopted as a standard library package
eventually.  I wonder if living inside the zope container package helps
or hurts those prospects.
Probably neither.  I doubt that there will ever be a standard Python
interface system.  I'm not going to hold my breath.  Guido argued
for having Zope's interfaces be in s subpackage (or have a weird name)
specifically to make it easier to add a standard interface package later,
assuming that a standard package might not be exactly the same as Zope's.
I understand the desire to carve out a package namespace that z3 can
reliably use without risk of collision with other packages.  I still
think that's less of a practical concern in the Python world
We've had colisions in the past. That's why we're being careful now.

(BTW, I think it was a mistake to have top-level persistent and transaction
packages. I think that will eventually come back to haunt us.)
The only way to avoid collissions is to pick stupid names (zthis, zthat).
I much prefer z.this to zthis. This assumes that we can make it easy to
install z.this into z.
 so I'd opt
for an approach that gets the non-Zope specific technologies into the
most hands of Python programmers.
I think that that's a different discussion.  The safest thing to do
for now is to continue using a container package.
Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)

2004-04-15 Thread Barry Warsaw
On Thu, 2004-04-15 at 10:23, Jim Fulton wrote:

 Each separately distributed package will have a DEPENDENCIES.cfg that is
 created by hand and that *constrains* dependencies on other packages. It
 makes explicit the intended dependencies. Dependencies not listed here
 are bugs.  Adding depenencies to this file should be considered a big deal.

That's very comforting!  I like that it forces developers to be
deliberate when adding cross-subpackage dependencies.

-Barry



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)

2004-04-15 Thread Barry Warsaw
On Thu, 2004-04-15 at 11:39, Casey Duncan wrote:

 Additionally (and Jim and I have discussed this amongst ourselves) I
 feel strongly that the dependancies should be enforced by tests. 

Good point.

 The dependancy tests might need to be separate from unittests because
 they would probably require an import hook or somesuch. Perhaps a tool
 like pychecker could be leveraged or extended to provide this service.
 At a minimum this test would need to be run before packaging a
 distribution, but ideally would happen more often.

I wonder if some kind of doctest could be added to the __init__.py of
the package that hooked __import__ and then attempted to import each
module in the package, tracking the imports.  Then complain about
anything not defined in DEPENDENCIES.cfg (and hmm, what to do about
standard library imports?).

Yeah, maybe some kind of pychecker hook would be better. :/

-Barry



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)

2004-04-15 Thread Stephan Richter
On Thursday 15 April 2004 11:39, Casey Duncan wrote:
 Additionally (and Jim and I have discussed this amongst ourselves) I
 feel strongly that the dependancies should be enforced by tests. That
 is, if you introduce and errant dependancy (by adding an import to a new
 package not in the stdlib or DEPENDANCIES.cfg) that it break a
 dependancy test.

I think this can be easily done using the finddeps.py utility. I think the 
hard work of finding all the dependencies in the first place is done. Note 
that Zope can also have dependencies in its ZCML files (which is handled by 
finddeps.py).

Regards,
Stephan
-- 
Stephan Richter
CBU Physics  Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)

2004-04-15 Thread Martijn Faassen
Stephan Richter wrote:
On Thursday 15 April 2004 11:39, Casey Duncan wrote:

Additionally (and Jim and I have discussed this amongst ourselves) I
feel strongly that the dependancies should be enforced by tests. That
is, if you introduce and errant dependancy (by adding an import to a new
package not in the stdlib or DEPENDANCIES.cfg) that it break a
dependancy test.


I think this can be easily done using the finddeps.py utility. I think the 
hard work of finding all the dependencies in the first place is done. Note 
that Zope can also have dependencies in its ZCML files (which is handled by 
finddeps.py).
Note that for checking dependencies in Python code I still think this 
tool could be improved by using technology from importchecker.py

http://cvs.zope.org/Zope3/utilities/importchecker.py

which can use Python's compiler module to lift all imports from source 
code, which I think is safer than the hand crafted parser approach 
finddeps.py takes now.

If somebody lets me know which API they want implemented for retrieving 
imports (and use of imports) I could do this lifting work myself.

Regards,

Martijn

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)

2004-04-15 Thread Stephan Richter
On Thursday 15 April 2004 13:22, Martijn Faassen wrote:
 Note that for checking dependencies in Python code I still think this
 tool could be improved by using technology from importchecker.py

 http://cvs.zope.org/Zope3/utilities/importchecker.py

 which can use Python's compiler module to lift all imports from source
 code, which I think is safer than the hand crafted parser approach
 finddeps.py takes now.

 If somebody lets me know which API they want implemented for retrieving
 imports (and use of imports) I could do this lifting work myself.

Fred has fixed that a while ago already (if I read the checkins 
correctly). :-)

Regards,
Stephan
-- 
Stephan Richter
CBU Physics  Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)

2004-04-15 Thread Martijn Faassen
Stephan Richter wrote:
On Thursday 15 April 2004 13:22, Martijn Faassen wrote:

Note that for checking dependencies in Python code I still think this
tool could be improved by using technology from importchecker.py
http://cvs.zope.org/Zope3/utilities/importchecker.py

which can use Python's compiler module to lift all imports from source
code, which I think is safer than the hand crafted parser approach
finddeps.py takes now.
If somebody lets me know which API they want implemented for retrieving
imports (and use of imports) I could do this lifting work myself.


Fred has fixed that a while ago already (if I read the checkins 
correctly). :-)
Well, perhaps I missed something. It changed to use the Python 
tokenizer, I think, if it wasn't doing this already. It doesn't use the 
compiler module, as importchecker does Anyway, I guess the tokenizer is 
fine too, and might even be faster for all I know, just seems an 
unfortunate duplication of work, plus I checked in importchecker for 
little reason. :)

Regards,

Martijn

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )