[Zope3-dev] Re: Grok 0.10.1 released!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: > Hi there, > > 2007-10-10 - The Grok project is happy to release Grok 0.10.1! Grok > 0.10.1 is a bugfix release of Grok, and the first outcome of the > Neanderthal Grok sprint that was hosted by GfU Cyrus in Cologne, > Germany, last week. > > The sole aim of this release is to fix Grok's installation story. > Releases of Zope 3 components that Grok relied on had the tendency to > break Grok. Since Grok now uses a fixed list of versions it relies on, > this problem should now be solved. The grokproject tool has also been > updated to 0.6, and now automatically uses the version list feature. > > To update grokproject to 0.6, please type the following: > > $ easy_install -U grokproject > > For more information about this release, including instructions on how > to update existing buildouts to use the version list feature, see > here: > > http://grok.zope.org/releaseinfo/readme.html > > What is Grok? > - > > Grok: now even cavemen can use Zope 3 > > Grok is a web application framework based on Zope 3 technology. Grok > aims to make Zope 3 technology more easy to use for beginners and > experienced developers alike. > > More about Grok: http://grok.zope.org grokproject appears to be broken:: [/home/tseaver/tmp] $ python VE-trunk/virtualenv.py --no-site-packages gtest New python executable in gtest/bin/python Installing setuptoolsdone. [/home/tseaver/tmp] $ cd gtest/ [/home/tseaver/tmp/gtest] $ bin/easy_install grokproject Searching for grokproject Reading http://pypi.python.org/simple/grokproject/ Reading https://launchpad.net/grok Best match: grokproject 0.6 Downloading http://pypi.python.org/packages/source/g/grokproject/grokproject-0.6.tar.gz#md5=b4901c46bcf1f0682c762506cdc76c47 Processing grokproject-0.6.tar.gz Running grokproject-0.6/setup.py -q bdist_egg --dist-dir /tmp/easy_install-q39YBI/grokproject-0.6/egg-dist-tmp-2DPklW Adding grokproject 0.6 to easy-install.pth file Installing grokproject script to /home/tseaver/tmp/gtest/bin Installed /home/tseaver/tmp/gtest/lib/python2.5/site-packages/grokproject-0.6-py2.5.egg Processing dependencies for grokproject Searching for PasteScript>=1.3 Reading http://pypi.python.org/simple/PasteScript/ Reading http://pythonpaste.org/script/ Best match: PasteScript 1.3.6 Downloading http://pypi.python.org/packages/source/P/PasteScript/PasteScript-1.3.6.tar.gz#md5=6a79da14870f0bbe9c1f7d4d12912437 Processing PasteScript-1.3.6.tar.gz Running PasteScript-1.3.6/setup.py -q bdist_egg --dist-dir /tmp/easy_install-TEYY_4/PasteScript-1.3.6/egg-dist-tmp-v8tUrz Adding PasteScript 1.3.6 to easy-install.pth file Installing paster script to /home/tseaver/tmp/gtest/bin Installing paster script to /home/tseaver/tmp/gtest/bin Installed /home/tseaver/tmp/gtest/lib/python2.5/site-packages/PasteScript-1.3.6-py2.5.egg Searching for PasteDeploy Reading http://pypi.python.org/simple/PasteDeploy/ Reading http://pythonpaste.org/deploy/paste-deploy.html Reading http://pythonpaste.org/deploy/ Best match: PasteDeploy 1.3.1 Downloading http://pypi.python.org/packages/source/P/PasteDeploy/PasteDeploy-1.3.1.tar.gz#md5=a14b360b4ddb0d3ca7aa9bad41d6c91c Processing PasteDeploy-1.3.1.tar.gz Running PasteDeploy-1.3.1/setup.py -q bdist_egg --dist-dir /tmp/easy_install-Yb3hMF/PasteDeploy-1.3.1/egg-dist-tmp-OyRTGE warning: no files found matching 'docs/*.html' warning: no previously-included files found matching 'docs/rebuild' Adding PasteDeploy 1.3.1 to easy-install.pth file Installed /home/tseaver/tmp/gtest/lib/python2.5/site-packages/PasteDeploy-1.3.1-py2.5.egg Searching for Paste>=1.3 Reading http://pypi.python.org/simple/Paste/ Reading http://pythonpaste.org Best match: Paste 1.4.2 Downloading http://pypi.python.org/packages/source/P/Paste/Paste-1.4.2.tar.gz#md5=109bd6b0edd6de3a5ee5feaf42acd6aa Processing Paste-1.4.2.tar.gz Running Paste-1.4.2/setup.py -q bdist_egg --dist-dir /tmp/easy_install-jdPUJu/Paste-1.4.2/egg-dist-tmp-6pbNoK Adding Paste 1.4.2 to easy-install.pth file Installed /home/tseaver/tmp/gtest/lib/python2.5/site-packages/Paste-1.4.2-py2.5.egg Finished processing dependencies for grokproject [/home/tseaver/tmp/gtest] $ bin/grokproject mytest Enter module (Name of a demo Python module placed into the package) ['app.py']: Enter user (Name of an initial administrator user): zope Enter passwd (Password for the initial administrator user): r00ler Enter eggs_dir (Location where zc.buildout will look for and place packages) ['/home/tseaver/buildout-eggs']: Creating directory ./mytest Downloading zc.buildout... Invoking zc.buildout... While: Installing. Getting section app. Initializing section app. Installing recipe zc.zope3recipes>=0.5.3. Getting distribution for 'zc.zope3recipes==0.6b1'. Error: Couldn&#x
[Zope3-dev] Re: Zope 3 releases?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Sutherland wrote: > On Mon, Oct 08, 2007 at 06:49:02PM -0400, Stephan Richter wrote: >> On Monday 08 October 2007 15:09, Tres Seaver wrote: >>> Presuming agreement on the "known good set" (KGS) term, I would think >>> that we have two candidates for what makes up "platform releases" >>> >>> Frozen Releases >>> >> I started commenting this section until I saw the one below. I personally do >> not see much benefit from the frozen release. That said, it would be trivial >> to create one from the updateable version below. I have already scripts for >> this, which are checked in as part of Jim's PyPI mirror tool. > > A frozen release is very useful for some people (as long as it also gets > security updates). That would be like being "a little bit pregnant." What you describe is an "updatable release" with a particular policy for how the updates are accepted into the KGS: you would allow new distributions for existing packges only where they included security fixes. Such a KGS would require meaintenance effort: - The maintainer would need to monitor devlopment of "upstream" projects, in order to know that new distributions had been released. - In some cases, the maintainer might need to create separate distributions for some upstream eggs, in order to strip out changes unrelated to a given security fix. That kind of KGS / release could certainly be useful, but it wouldn't be, nor serve the same goals as, a frozen release. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHDOfq+gerLs4ltQ4RAlgVAKCo6aiPdlLAgQKCBvnJ8nAw8UCktACfdQMd UauIuWnZWDxxokOIbrH62xs= =Xyh7 -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3 releases?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: > On Oct 7, 2007, at 6:25 AM, Lennart Regebro wrote: > >> On 10/6/07, Jim Fulton <[EMAIL PROTECTED]> wrote: >>> - We need to decide what a Zope 3 release is (or maybe multiple >>> flavors). I favor copying the linux experiences, but have an open >>> mind. >> I'm not sure what you mean with that, > > I mean we need to decide what a release is. Presuming agreement on the "known good set" (KGS) term, I would think that we have two candidates for what makes up "platform releases" Frozen Releases - A frozen release would consist of: - A single, "frozen" KGS (index pages cannot change after release). - Scripts / tools which target that KGS, and create from it a standalone environment whcih includes the selected diestributiongs for each project in the KGS. E.g.: o An easy_install'able meta-egg with pinned versions, referencing the KGS index as 'index_url'. The egg would also include scripts and other entry points used to configure the platform environment (e.g., install zope.conf and site.zcml from skeletons, etc.) o A bootstrappable zc.buildout with "pinned" versions for all packages, or which relies on the frozen meta-egg for pinning. o A 'virtualenv' derivative, again probably leveraging the "frozen" egg. It would probably be fairly straightforward to generate the "meta" egg given the manifest. In fact, the "meta" egg should probably load the pinned versions from a config file which was also used to generate the frozen index page. These releases would be useful for: - Testing third-party packages which extend the platform. - Reproducing bugs reported against the platform - Giving to newbies as a "safe" starting point. The public versions of them would probably *not* be good for use in production deployments, because they cannot be updated with bugfixes. Some users might maintain their own versioned frozen releases for such uses, and handle updates by re-installing and migrating their data). Such a release would be analogous to a bootable ISO for a Linux distribution: if you run from the CD, you *know* what software is present, without any question. I would note that the script I posted a week or so ago for building package index pages from a directory full of source distributions would be a perfectly adequate tool for constructing such a KGS: simple copy or link all the "frozen" distributions into a directory and run the script. Once you've verified that the installation regime works from the generated files, you *never touch them again*. Updatable Platform Releases - --- An updatable platform release would consist of: - A KGS whose index pages were manually updated from time to time with carefully-selected new distributions of existing packges. - An installation regime, as above, which uses the KGS as its 'index_url', but *pins no packages* (whether in the "meta" egg, buildout.cfg, or whatever). o This regime should also contain / bootstrap scripts which couls be used to do automated updates from the KGS, like 'yum update' / 'apt-get upgrade'. In this case, generating the "meta egg" (or equivalent) should be unneeded: that egg could just be managed within the KGS itself. In a typical environment, the meta egg would likely never be updated all all (because it contains no software beyond the parts used to generate the environment). Such a relase would be analogous to an installed Linux distribution, with update repositories pre-configured. Maintaining the KGS in this case is harder, and could probably use a little more tooling. Once we have the tools, then tweaking them to allow generating a "frozen" release will be simple. In that mode, the two flavors of release here could be thought of as like "tags" and "branches" in the CVS sense (not SVN, which doesn't really have tags). Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHCoBx+gerLs4ltQ4RAnz3AJ0fBLZfO/oSbBr37L1LGp/bpAAtZQCgs0gg zShIqAl+sFbdCRKMHOhAH4A= =vl1V -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Known-good-sets problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: > Hey, > > Another point of feedback: > > I saw Stephan's mail on a (partially new) toolchain and somewhat > extensive workflow on using it. I'm a bit surprised a toolchain is > necessary and that the workflow is so involved. With Grok's approach > using extends in buildout, we can just publish such a list on a dumb > website without any tools whatsoever. I'll agree that I don't see a need for much of a toolchain. Effectively, the index pages are just a set of N+1 static HTML pages (where N is the number of distutils "projects" managed by the index) with mirrored copies of all the distributions in some well-known (and guarded ;) location. > Since you're effectively mirroring the cheeseshop anyway, why not rely > on the cheeseshop entirely and just publish the version lists? If you don't mirror the actual distributions, then you are at the mercy of the project owner on the cheeseshop, who is free to remove or (worse) update-in-place an egg you rely on. This is why Debian mirrors the "pristine" tarballs of packges, and why RPM bundles them inside the SRPMs: *other* people and their software distribution mechanisms can't be relied on when repeatability is your goal. - -Tres.- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHCnZA+gerLs4ltQ4RApxHAKCbXq2QkS3l4kD7Q0/qrssPn2zTYACfRjvb vVYlNIbZ6JwKVGY2jkxcXoA= =B++h -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: I'd lobe to merge the zope3-dev and zope-dev lists
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: > Any objections? > > This would basically involve retiring the zope3-dev list and moving > zope3 developers to the zope-dev list. +1. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHCkzF+gerLs4ltQ4RAjD5AKC+7vl0DlWSJYqHTlrNADqRFRyRLwCgz+qU u5liXF5Lu25oOk5OPY+TZjY= =SXR9 -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: zope.dottedname doesn't have a CHANGES.txt (again?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lennart Regebro wrote: > On 10/3/07, Stephan Richter <[EMAIL PROTECTED]> wrote: >> I want tools! Actually, I just want one tool. 70% of the release process is >> repetition and that needs to be factored into a tool. This tool should have >> been written before the Zope trunk was blown into pieces, but it wasn't. :-( > > I'd recommend fixing bundleman to be able to support making eggs. > Bundleman will look at the changes, suggest versions out of that, > refuse to release if there are no changes set, create the tag and make > the release from the tag. > > It's written in Python, in clear and understandable code by eminent > programmer Benoit Delbosc (of funkload fame). > > http://tinyurl.com/ye8dsk > > It currently only makes releases as tgz, but adding eggs should be so > hard (it's done by calling setup.py anyway if I remember correctly). I would prefer that we quit releasing non-source distributions at all; the exceptions would be Windows eggs for packages containing extensions. Any binary egg for Linux is a disaster waiting to happen: setuptools will happily install it into a Python which has incompatible compilation options (UCS4 vs UCS2, for instance). AFAIK, the Mac toolchain, like the Linux one, is happy to create locally-installable binary eggs from the sdist versions. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHA9Fy+gerLs4ltQ4RAkIDAKCjbFDE6wYR1MBTcGOMQFjPmtbkegCgx4Vn cNfrlWm56+aUWH5xBvbalgg= =lqQe -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Known working sets II [was: Eggification redux]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
> Hey,
>
> [eggs in debian]
>
> Okay, I can see this as an additional, more stably maintained resource
> of eggs than the cheeseshop. That might indeed be helpful.
>
>> Now, how would you use the Grok gated community with the sqlalchemy
>> gated community if they had common dependencies, and those dependencies
>> were at different versions in the two communities?
>
> I don't know. :) I don't know how a gated community is supposed to work.
>
>> Of course, you could make one _very_ large gated community and "freeze"
>> it as a release every now and then. Er, basically the same as what
>> distros are doing, hopefully making their life much easier;)
>
> One of the issues is that it doesn't solve my problem if you just have
> a big one. You'd need a gated community per *version* of Grok in order
> to make sure no newer eggs sneak into the project after release.
Correct. Such a "protected mirror" provides repeatability: for
instance, if someone installs from the cheeseshop, and then reports a
bug which can't be reproduced when installing from the mirror, then the
fix is obvious. If no distribution of a given project is available in
the mirror, then the user should know that "caveat emptor" applies: the
mirror defines the "supported" package set.
Essentially, the mirror externalizes the 'install_requires' with pinned
version numbers into an external website, along with the guarantee that
the specified distributions will remain available, even in the event
that somebody makes a release management booboo on the cheeseshop.
I can envision URLs which look like:
- Copies of all distributions ever used with grok:
http://grok.zope.org/dist/
- Symlinks of the specific distributions known to work with grok 0.10:
http://grok.zope.org/dist/grok-0.10/
- Generated 'simple' API page for grok 0.10 ('--index-url' target):
http://grok.zope.org/dist/grok-0.10/simple/
One could of course write a webapp to manage these sets, but that feels
like it might be overkill, unless the application did more stuff as well
(like maybe generating buildout.cfg files, or virtualenv derivatves).
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFG/+qZ+gerLs4ltQ4RAsqZAJwKa7GTCnwcAOUl7492STPbt9WjzACfVEzH
7MLRS6zsM2+ZZqOgvcrH7CE=
=cUuO
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Known working sets II [was: Eggification redux]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: > On 9/28/07, Tres Seaver <[EMAIL PROTECTED]> wrote: > [snip] >> Total effort involved in maintaining the "gated community" then becomes >> keeping a set of tarballs available at some web-downloadable location, >> and re-running the script after adding / removing them to regenerate >> the index. > > How many of these communities are you going to need? Why can't you > simply maintain a list of exact versions with version numbers to pull > from the cheeseshop instead? Because you can't trust that packages will not get removed, or even re-released under the same version number, on PyPI: not everybody has the same "package hygeine" ethos. > This is already possible with the > versions feature of buildout. I want something where I can maintain > these lists better for frameworks inside packages, but if you're just > going to make lists of packages in the end, why mirror? Is this > because you're using easy_install and you can't use the versions > feature? Is it because you don't use buildout? I've been using buildout and its precursors for *years*, and I still have my "repeatable" builds break on occoasion, e.g.: - The Postgres guys decide to yank an older package version from their servers because they've released a newerone. - Somebody does "repository surgery" in a way which breaks my checkout (e.g., because Subversion checks the revision number *after* traversal rather than before). - Somebody uploads a "fixed" tarball of a relase without bumping the version number. In the end, if you want predictable / repeatable deployment, you have to mirror the sources. The fact that easy_install's '--index-url' feature makes such a mirror convenient is just a bonus. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG/RlI+gerLs4ltQ4RAjEJAKDTokuKZSiLaJbHKhyQ+wOBvZHpnwCgz8rt wF5HH7htyMh/+VVyTeTpSQ4= =crEB -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Known working sets II [was: Eggification redux]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tres Seaver wrote:
> Anybody running against the Cheeseshop today is *more* on the bleeding
> edge than a sysadmin whose production boxes are running 'sid': Debian
> has cultural constraits, even for that distro, which are vastly more
> restricted than the Wild West which is PyPI.
>
> The only solution I can see is to create filtered subsets / mirrors of PyPI.
>
> Exactly. Without some way to impose a "gatekeeper" role on the package
> pool from which a given deployment draws, we can't have any
> deterministic outcomes when installing packages.
OK, here is a sample "gatekeeper" script, intended to be run from within
a directory full of source distributions. E.g.:
$ cd /path/to/dist.example.com
$ ls
abc-1.2.3.tar.gz abc-1.2.4.tar.gz ghijk-2.3.4.tar.gz
$ python /tmp/makeindex.py *.gz
Parsing: abc-1.2.3.tar.gz
Parsing: abc-1.2.4.tar.gz
Parsing: ghijk-2.3.4.tar.gz
Project: abc
--> 1.2.3 abc-1.2.3.tar.gz
--> 1.2.4 abc-1.2.4.tar.gz
Project: ghijk
--> 2.3.4 ghijk-2.3.4.tar.gz
Assuming that the directory is the root of an Apache virtual domain,
'dist.example.com', the script creates a 'simple' subdirectory, with
an index listing the projects corresponding to the tarballs. Each
project ('abc', 'ghijk') gets a subdirectory with an index pointing to
its tarballs.
At this point, from a fresh virtualenv, you can install those packages
without risk of pulling anything from the Cheeseshop:
$ bin/easy_install --index-url=http://dist.example.com/simple ghijk
Total effort involved in maintaining the "gated community" then becomes
keeping a set of tarballs available at some web-downloadable location,
and re-running the script after adding / removing them to regenerate
the index.
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFG/D9a+gerLs4ltQ4RAtZrAJwPrSe+vAaLTNF+XrrdyPY6bFXgTgCgzqOV
ssgeiDB9/whhld4DyylsQxA=
=f2tL
-END PGP SIGNATURE-
makeindex.py
Description: application/httpd-cgi
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: faulty releases and pypi access [update]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: > Hey, > > On 9/27/07, Tres Seaver <[EMAIL PROTECTED]> wrote: > [snip] >>> I don't like it either. I thought we resolved this though so I'm not >>> sure why we're discussing this. CHANGES.txt in the root dir it is, >>> right? >> - -1. I argued for putting the CHANGES.txt and the "real" README.txt in >> the *package* dir, making them available in the *installed egg*, not >> just the source ditribution. > > Okay, I hadn't read it that way as the word 'package' is ambiguous. > That seems completely against the way everybody else does this. Why is > having this available in the installed egg so important? Because it is a valuable clue to the guy scratching his head trying to figure out why something isn't working after 'easy_install' runs: the source distribution is only around on his system transiently. The changelog, along with the README is an essential part of the package's documentation, and should be installed with the egg. Because distutils / setuptools doesn't allow for installing non-package data, we have to put them in the package. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG++K2+gerLs4ltQ4RAqJsAJ4io55zfVQeYWeVwDiC72/VQS7LPwCfX7sO tmi7zuaUDF3FHs9V3vpPh2w= =wnDh -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: faulty releases and pypi access [update]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: > Hey, > > On 9/27/07, Jim Fulton <[EMAIL PROTECTED]> wrote: >> On Sep 26, 2007, at 8:26 PM, Tres Seaver wrote: > [snip] >>>> Including a file other >>>> that README in the root requires extra effort that I don't want to >>>> require -- writing setup.py files is hard enough as it is. >>> Put the "real" README.txt and CHANGES.txt in the actual package: the >>> version which is a peer of 'setup.py' should be a stub which points to >>> the "real" versions. >> I can live with this, but I don't like it. It feels more complicated >> to me. > > I don't like it either. I thought we resolved this though so I'm not > sure why we're discussing this. CHANGES.txt in the root dir it is, > right? - -1. I argued for putting the CHANGES.txt and the "real" README.txt in the *package* dir, making them available in the *installed egg*, not just the source ditribution. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG++AV+gerLs4ltQ4RAv11AJ48x6iioc9AWavIZS5zvQvpR/X1dwCgsuro 3CvFwTcmCfYqXFpICxDGCxk= =+T+6 -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Why do we restrict our egg testing?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: > On Thursday 27 September 2007 08:43, Benji York wrote: >> Roger Ineichen wrote: >>> Can anybody tell me why we restrict our test setup >>> in zope eggs and only use a subset of package for >>> our test setup? >> I don't know what you're asking, so I can't tell you why it is . >> >>> Why do we not use a Zope3 meta egg which contains all >>> our zope packages as a test base. This whould allow >>> us to test the same we have in the zope3 trunk and let >>> us run *buildout/test -s zope* from within each egg. >> Perhaps because there isn't a Zope 3 meta egg. > > Roger is suggesting that we should have one, so that problems are detected > early. Any comments on that? Why would we want to pull in all of Zope3 as a dependency (worse, a hidden one) before testing an egg? If the egg's dependencies are broken, I *want* the tests to fail. I don't think testing against a "fat" meta-egg satisfies that goal. Fix the egg so that its 'install_requires' or 'tests_requires' are sufficient to make the tests pass instead. I thought Roger was one of the folks looking to *reduce* the set of dependencies his application had on zope3 coee -- testing against the meta-egg actually makes that problem worse. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG+78l+gerLs4ltQ4RApFIAJ9byQ03OzbOeYK8HAt+QFJMHQkxcwCdF1XJ 02Wi+nxNV3UnkNk2qaGIN6I= =r6Bz -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Known working sets II [was: Eggification redux]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
> Hey,
>
> Tres Seaver wrote:
> [snip]
>> I think that replacing 'index_url' with a "gated community" of packages
>> is the only path to sanity here: the contract of the Cheeseshop (share
>> new releases of all packages with everyone ASAP") is incompatible with
>> our goals ("ensure that users can install a given package and its
>> dependencies, and have them work").
>
> I already replied to this, but let me point out why I think such a gated
> community would not be *sufficient* for my purposes.
>
> I want to be able to release package X, and have a way for other people
> to install it and it not break, ever. This can be done with hard version
> numbers in install_requires today, but people object to this reasonably
> as it would reduce flexibility of component reuse. If we want to have a
> way to reproduce installations *exactly* and we want to still allow
> flexibility, a gated community while hopefully increasing the quality of
> individual releases still won't guarantee that package X won't break
> when someone else tries to install it.
If package 'X' points its 'index_url' to the GC, then anybody trying to
install 'X' will look up / pull dependences from the GC: that setting
takes the Cheeseshop completely out of play.
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFG+71h+gerLs4ltQ4RAq2eAKC6MCvwyTz2e+7S9B9XmbbNccXZrwCeLCNn
gzwHm/h1L8GfGkddhwS2YCI=
=BpzN
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Known working sets II [was: Eggification redux]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
>> I think that replacing 'index_url' with a "gated community" of packages
>> is the only path to sanity here: the contract of the Cheeseshop (share
>> new releases of all packages with everyone ASAP") is incompatible with
>> our goals ("ensure that users can install a given package and its
>> dependencies, and have them work").
>
> Why don't you think it can be solved by having packages themselves
> state preferred versions? The cheeseshop can be a festering pool of
> madness, as long as the packages I pull from it have reasonable
> preferred versions, I should be fine, right?
A few things:
- Your solution requires a new feature in setuptools, whose development
velocity has dropped off pretty sharply of late. Maybe you've got a
patch in hand already, at which point you could offer a temporary
fork while the feature makes it way into an official release.
- The proposed feature makes solving the package dependency graph
harder, rather than easier: what if grok recommends a different
version of 'zope.interface' than some other component recommends?
- People do remove releases from the Cheeseshop, with various
justification. If you want to guarantee that somebody will be
able to recreate the known environment, even in the face of missing
distributions, you have to mirror the "blessed" distributions.
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFG+6+K+gerLs4ltQ4RAknhAJ9UHb3MWhufwJyCGQv3vhosZgFNugCeMzAB
yOJcbXOmbo4Yd1OrbVF1MY0=
=G7tX
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: reasonable syntax for multi-adaptation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: > On Sep 26, 2007, at 3:37 PM, Dieter Maurer wrote: > >> Jim Fulton wrote at 2007-9-26 15:10 -0400: >>> ... >>>> Jim Fulton wrote at 2007-9-26 11:29 -0400: >>>>> ... >>>>>> IFoo(x) >>>>>> IBar(multi=(x,y)) >>>>> Actually, that is not the case. If x already provides IFoo, >>>>> then in >>>>> the first case, the existing object is retuned. Nothing is >>>>> instantiated. OTOH, in: >>>>> >>>>> getMultiAdapter([x], IFoo) >>>>> >>>>> or >>>>> getAdapter(x, IFoo) >>>>> >>>>> either there is an error or some factory will be called. x >>>>> won't be >>>>> returned unless the factory happens to return it. >>>> Is this not an irrelevant implementation detail? >>> No, the specified behavior is different. >> Hm. But "getAdapter" and "getMultiAdapter" may return "x" as well >> (when the factory decides to do this). >> >> Thus, why is it relevant? > > Because they don't take into account what x already provides. They > will always call some factory. Also, they never call __conforms__. Why does the caller care? She just wants an object which will provide the 'IFoo' contract on behalf of the passed context. If 'x' is capable of providing 'IFoo' without help, then failing (or worse, returning a less-specific factory result) when calling 'getAdapter' is the Wrong Thing (a "least surprise" violation, if nothing else). Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG+wLR+gerLs4ltQ4RAuojAJ90QTKCzaEonLYPTqmJ+5SJpz1eDwCgyy4K w59LMYo7ur+GCfEwAy+w5aM= =Weg9 -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: reasonable syntax for multi-adaptation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: > Hey, > > My opinions: > > It'd be nice if getMultiAdapter's functionality was in reach without > typing: import zope.component; zope.component.getMultiAdapter. The > IFoo() single adapter lookup shows us a way to make this possible: a > method (in this case __call__ on the interface). It does bother me on > occasion that I need to invoke multi adaptation in such an entirely > different way. I must also note that it's a very common intuition to > want to do something like IFoo((a, b)). > > Even though my intuition is usually like Jim's and prefer to have two > different methods, given different semantics, I consider the differences > in semantics here such a grey area I'm on the fence. > > That the object itself is returned if it already provides the interface > in single adaptation is a difference in semantics, The fact that the object may be returened as its own adapter is logically opaque to the caller, who should properly care only that the returned value implements the interface. For exactly the same reason, I think that calling an iterface with an *empty* context list could reasonablly be construed as a 'getUtility' request: the fact that a factory is called for one, and not the other, is irrelevant *to the caller*. > but since there's > just no possibility of doing so in the case of multi adaptation anyway, > you can argue whether this is a difference in semantics or not, just > some semantics that doesn't apply. __conform__ is a bigger difference, > but given that polymorphism abounds in object oriented code, having > different behavior with different inputs is not *that* surprising either. Exactly. > Anyway, if we want to split methods, I'm fine with a properly named > method for multi-adaptation on the interface. For completeness' sake > you'd also want a properly named method on the interface for > single-adaptation. > > IFoo.adapt() for normal adaptation > IFoo.multiadapt() for multi adaptation I'd rather have 'adapt' take *args for the contexts, and keywords for extras (like name). > sound reasonable to me. We then explain that if you call IFoo directly, > IFoo.adapt is called. These could then also be extended to support named > adapter lookup and such. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG+wHp+gerLs4ltQ4RAkyiAJ0biniCdvVIs5vgVCzSm1ISzbWF5QCfQ7FQ iQsVQ0u8q1ZWg2UEGOx43qY= =HlvT -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: faulty releases and pypi access [update]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: > On 26 Sep 2007, at 22:34 , Benji York wrote: > >> Philipp von Weitershausen wrote: >>> Stephan Richter wrote: >>>> Because I disagree with that, since you cannot know the next >>>> version. >>> You can always know the minimum version. If you just released >>> 3.4.2, I think it's sensible to point the next release to 3.4.3. >>> If you later decide that you really need a feature release, you >>> can always bump to 3.5.0a1 (which would be the first release in >>> the 3.5.x series). >> Why not leave the version totally out of the setup.py in the trunk? >> After branching for a release we can set the version (e.g., 1.2), >> make a release, and tag the branch. >> >> We could either leave the version on the branch at the "last" >> release or continue the trend of mad bumping and have it at the >> "next" release (which since this is a branch, we can actually >> predict). >> >> I prefer the "last" version, but "next" would work too. > > setuptools suggests setting it to the "next" version. Apart from the > fact that it makes more sense to me, the biggest reason I can see is > the development egg use case. A development egg from the repository > should have a newer version than the latest released egg. If it were impossible to create an 'sdist' or 'bdist_egg' from such a checkout, I would be OK with this. However, history shows that people *will* make distributions from such "not-ready-for-prime-time" checkouts, at which point the damage is orders of magnitude bigger than any value derived from convenience in installing the 'develop' egg. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG+v44+gerLs4ltQ4RAkc9AJ9I1GobzNfnIJdtM0BgAUV5TDeVhwCffe5S m86ebz0mOlkA75MSZ+goGus= =x3mI -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: faulty releases and pypi access [update]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: > On 26 Sep 2007, at 23:18 , Jim Fulton wrote: >> On Sep 26, 2007, at 4:34 PM, Benji York wrote: >> >>> Philipp von Weitershausen wrote: >>>> Stephan Richter wrote: >>>>> Because I disagree with that, since you cannot know the next >>>>> version. >>>> You can always know the minimum version. If you just released >>>> 3.4.2, I think it's sensible to point the next release to 3.4.3. >>>> If you later decide that you really need a feature release, you >>>> can always bump to 3.5.0a1 (which would be the first release in >>>> the 3.5.x series). >> Gary and Benji made me pay attention to this point. :) >> >> I *really* don't like setting the version to the number for the >> next release, since one often doesn't know what it is. > > Maybe. However, when you do the actual release then, you're still > going to have to find out which version number to use. On release > branches this is a trivial step, of course: You just look at the > latest tagged version and increment accordingly. On the trunk it > might be trickier. After 1.0, do we have 1.1? Or 2.0? > > Maye this aspect isn't such a big deal, though. > >>> Why not leave the version totally out of the setup.py in the trunk? >> Benji and Gary won me over to this point of view. :) > > There's a *really* good reason for putting the upcoming version > number in setup.py, though: development eggs. - -100. 'development eggs' which get released into the wild are an abomination of desolation, and should be avoided at *any* cost. (I'm assuming that you mean eggs / distributions which get uploaded to some package repository, rather than being installed via 'setup.py develop'). > Let's say X depends on Y and I'm developing them simultaneously as > development eggs in one sandbox (e.g. buildout). I add a feature to Y > that I'd like to use in X. That means I'll have to change X's version > dependency regarding Y so that it now depends on Y>a.b where a.b is > the latest release that didn't have the feature I added. Logically speaking, you *can't* release Y with the new requirement until *after* a release of X is availabe with the required feature: while they are both in development, hacking on Y's 'install_requires' is pointless. Once X is released with the new feature, *then* you can update the develpoment egg for 'Y' to mandate that version of 'X': at that point, you should be removing the development egg of 'X', in order to verify that 'Y' works with an installable 'X'. > Will Y with the setup.py stating version='unreleased' satisfy the > Y>a.b requirement that X (rightfully) has? If not, then I think we > have a problem. If yes, then I find that very confusing. 'Y' can't be changed simultaneously with 'X': that is the nature of dependency management. > I know that if Y's setup.py stated version='a.b-dev', it will work. > This what my guide currently suggests (including taking it out just > for release tags). I would *never* check in a release of 'Y' which mandated a non-released version of 'X'. >>> After branching for a release we can set the version (e.g., 1.2), >>> make a release, and tag the branch. >> We should not require branches. I would only bother creating >> maintenance branches when they are needed. > > +1 Agreed. Creating a release branch in SVN from a tag is trivial, and therefore shouldn't be required "ahead of time." >> Z, B, G, and I propose the following: > > Who's Z? :) > >> - Leave the version # out of setup.py on the trunk and on branches. >> >> When it is time to make a release, either from the trunk or from a >> maint branch: >> >> - Update changes.txt, adding a heading for the new # and date >> >> - Create a tag >> >> - check out or switch to the tag >> >> - Set the version in setup.py on the tag. Check it in. >> >> - Make the release from the tag. > > I could live with that, even with the fact that you'd be modifying a > tag, as long as it's done in this exact order and the only > modificdations to a tag woudl be setting setup.py. I'm fine with making "packaging only" changes to a tag. > I still see the development egg case the best argument for putting > the next anticipated version number into setup.py. I think the > comp
[Zope3-dev] Re: faulty releases and pypi access [update]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: > On Wednesday 26 September 2007 17:34, Jim Fulton wrote: >> On Sep 26, 2007, at 5:28 PM, Stephan Richter wrote: >>> On Wednesday 26 September 2007 17:18, Jim Fulton wrote: >>>> - Update changes.txt, adding a heading for the new # and date >>>> >>>> - Create a tag >>>> >>>> - check out or switch to the tag >>>> >>>> - Set the version in setup.py on the tag. Check it in. >>>> >>>> - Make the release from the tag. >>> Changing tags is not that good. I'd rather check in a aversion number >>> then. ;-) >> This is exactly what we've been doing for Zope 3 releases -- for the >> same reason. I think it is the one acceptable and reasonable change >> to a tag. The benefit of forcing us to release from a tag is, imo, >> significant. > > Here is a problem that I discussed with Marius earlier today. > > I often do not know whether all my setup.py settings are correct until I try > to upload a release. You should *never* be uploading a release that you don't already *know* is correct. < I frequently get the "Development Status" classifier > wrong and I won't be told it is wrong until I try to register the release. If you are using 'setup.py register upload' to do your checking, you need a better tool: the consequences of carelessness are too significant (bad releases punish everyone *else*). > So I usually create the release first and upload it and after that create the > tag. - -100. Get it right, check it in, *then* upload the distribution. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG+vrc+gerLs4ltQ4RAj1gAJ4pODs1F2kHFNDHS7JWNOFcQ0k8lACg0Szp q7CgaDorr2xdLLPtp+N90VM= =8P1J -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: faulty releases and pypi access [update]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Benji York wrote: > Philipp von Weitershausen wrote: >> Stephan Richter wrote: >>> Because I disagree with that, since you cannot know the next version. >> You can always know the minimum version. If you just released 3.4.2, I >> think it's sensible to point the next release to 3.4.3. If you later >> decide that you really need a feature release, you can always bump to >> 3.5.0a1 (which would be the first release in the 3.5.x series). > > Why not leave the version totally out of the setup.py in the trunk? > After branching for a release we can set the version (e.g., 1.2), make a > release, and tag the branch. > > We could either leave the version on the branch at the "last" release or > continue the trend of mad bumping and have it at the "next" release > (which since this is a branch, we can actually predict). > > I prefer the "last" version, but "next" would work too. I prefer neither, as I don't want to encourage people to make releases without doing the bookkeeping required to get the versions right. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG+vm++gerLs4ltQ4RApbhAJ9Anxm8SDCG+b0pk6MbpPT/cqaWTgCfYebK drwMpQGfEvPMyT7x5nLAwYg= =1BCs -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: faulty releases and pypi access [update]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: > Jim Fulton wrote: >> On Sep 26, 2007, at 1:18 PM, Fred Drake wrote: >> >>> On 9/26/07, Martijn Faassen <[EMAIL PROTECTED]> wrote: >>>> What does one need to tell setup.py to make sure CHANGES.txt is >>>> available? I understand it isn't by default, then? Hm, it does appear to >>>> be there by default. I checked grok 0.10's tgz and it's there, and we >>>> didn't do anything special. >>> Do you mean available in the unpacked sdist, or as part of the >>> installation? I don't think any of README, README.txt, CHANGES, >>> CHANGES.txt (from the root of the distribution, not from inside the >>> package) are actually installed. If they are, I'd love to know where. >> By default READM(.txt) is installed in a source distribution. Anything >> else in the root (aside from setup.py of course and source files >> themselves) aren't without extra setup chants. (These chants can be >> figured out with some effort. I never remember them, so, if I want to >> do something like this, I have to figure them out again or try to find >> an example with them.) > > Actually, no package data is ever included unless you're either > > * working from an svn checkout, in which case setuptools will use the > list of which files are in svn and which aren't as a hint of what to > include and what not > > * creating a MANIFEST.in file to tell setuptools what to include explicitly. or you write your own package finder. Frankly, anybody who is making package releases from anything other than a versino-controlled checkout is insane. Further, anybody who finds the effort of creating a "fresh' checkout bevore making a release too burdensome should consider themselves self-selected out of the "release manager" pool. I'm *not* kidding about that: taking shortcuts durng the release process transfers pain / cost to everyone downstream. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG+vll+gerLs4ltQ4RAh0NAKCKZCn7wcd3tgqghK92MfA7WKwkxQCgrTo6 78QLmHGfbMy1oBOrQy+i3k0= =wtNc -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: faulty releases and pypi access [update]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: > On Sep 26, 2007, at 1:18 PM, Fred Drake wrote: > >> On 9/26/07, Martijn Faassen <[EMAIL PROTECTED]> wrote: >>> What does one need to tell setup.py to make sure CHANGES.txt is >>> available? I understand it isn't by default, then? Hm, it does >>> appear to >>> be there by default. I checked grok 0.10's tgz and it's there, and we >>> didn't do anything special. >> Do you mean available in the unpacked sdist, or as part of the >> installation? I don't think any of README, README.txt, CHANGES, >> CHANGES.txt (from the root of the distribution, not from inside the >> package) are actually installed. If they are, I'd love to know where. > > By default READM(.txt) is installed in a source distribution. > Anything else in the root (aside from setup.py of course and source > files themselves) aren't without extra setup chants. (These chants > can be figured out with some effort. I never remember them, so, if I > want to do something like this, I have to figure them out again or > try to find an example with them.) > > If we are going to have a change log, which we should, I would prefer > it to be included in source distributions. I want them present in the *installed* egg, not just in the source distribution: setuptools doesn't preserve source distributions after creating / installing the '.egg' version. > Including a file other > that README in the root requires extra effort that I don't want to > require -- writing setup.py files is hard enough as it is. Put the "real" README.txt and CHANGES.txt in the actual package: the version which is a peer of 'setup.py' should be a stub which points to the "real" versions. > I'm not crazy about Tres' idea of putting these files in the Python > packages themselves, but it does have the advantage that it causes > the files to be included in eggs as well as source distributions. Not having those files available after installing is a complete non-starter for me. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG+viq+gerLs4ltQ4RAtNfAJ9jNe3abDAUpCP/0a7Dy+Zc0XI25QCgxwgp QDrrR4nwci92k2diKxMvmQc= =upXO -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Known working sets II [was: Eggification redux]
and over again as
> something goes wrong with some egg somewhere. I want these dependencies
> pinned down hard. That said, I believe there are ways to solve these
> problems without hardcoding them in install_requires. I hope we can have
> the benefits of weak dependencies while having the safetly of hardcoded
> ones. See here:
I think that replacing 'index_url' with a "gated community" of packages
is the only path to sanity here: the contract of the Cheeseshop (share
new releases of all packages with everyone ASAP") is incompatible with
our goals ("ensure that users can install a given package and its
dependencies, and have them work").
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD4DBQFG+vfY+gerLs4ltQ4RAgS0AJ9B+q0BibgbK7EZ5LyutI0l0UyTDQCVFKMg
7cBORRpQtq4Nc1YbT9yoYg==
=ROuj
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: faulty releases and pypi access [update]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: > On Sep 26, 2007, at 10:42 AM, Stephan Richter wrote: > >> On Wednesday 26 September 2007 10:40, Jim Fulton wrote: >>>> What about using CHANGES.txt, which we should be maintaining anyway? >>> I agree with a change log. CHANGES.txt is difficult to get included >>> in distributions. Having one requires a more complex setup.py. I'd >>> rather recommend including a change log in README.txt. >> -1. I don't like that. We include CHANGES.txt via the long >> description; that's >> good enough for me. > > Do you think that the change log should be included in the distribution? +10. The cheeseshop metadata is not where I would expect to look for a changelog; having it readable there is only helpful *before* I've downloaded. FWIW, I think that both README.txt and CHANGES.txt should be "package data", so that they are discoverable after installing an egg. The top-level README.txt should be boilerplate, and point to those files (the setup.py process can then stitch them all todgether). Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG+nfe+gerLs4ltQ4RApwzAJ9WjIb1eWRU1LZA8Tm6hAnVLgcnnwCgovHP HlNNaXNmE8X/4nz4oVVpPmE= =PqY/ -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: faulty releases and pypi access [update]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: > On Wednesday 26 September 2007 04:49, Christian Theune wrote: >> The issue is that the eggs were released as ZIP files and for some >> reason those don't work correctly with the data files. >> >> I can reproduce the problem by creating the packages myself as ZIP files >> (doesn't work) and then as tar files (does work). > > Okay, thanks a lot for this research. So this is a problem that noone could > anticipate. Roger tried the eggs on his machine and they worked there. > > So that's something we learned: We have to make tag.gz releases. Why would we zip / tar files up by hand, rather than using 'setup.py sdist'? > BTW, which OS so you use? Roger told me he did several releases with Windows > at Lovely Systems and all was fine there. But then everyone else at Lovely > has Macs. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG+nKD+gerLs4ltQ4RAl66AKCtLSJDOAVavsYVpw9A5EgIq1zg+QCgy5jc cjUVQfmRlkGYFqZtuCy8fUg= =/bGl -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: faulty releases and pypi access [update]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: > On Wednesday 26 September 2007 05:02, Christian Theune wrote: >> Hmm. While doing that I also noticed that we were at 3.4.0a1 yesterday >> evening. The stable release was made from that without making a >> maintenance branch and bumping the trunk to 3.5. > > There is conflicting information here. :-) Some people say we need branches, > others say we don't. And where is an agreed-upon document that you have to > list the next version in the setup.py file after the release? Because I > disagree with that, since you cannot know the next version. +1, The trunk should *always* say 'unreleased' or 'trunk', except in the five minutes before cutting a release tag (if not using a release branch). Release branches should have '-branch' or something appended to the version, except just before cutting a release tag. Anything else makes it too easy to cut a premature / broken release; such mistakes are going to damange our story if we don't get out ahead of them. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG+nGq+gerLs4ltQ4RAtrkAJoDIeCeHW3BVdlWYLklwf6MrOV2MwCgy43W enYWkDaVC0IHZV4Fb0K7KDA= =WGvo -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Known working sets II [was: Eggification redux]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 (CC'ing the Python distutils list, which is where setuptools development is discussed; maybe I should be including the catalog-sig too, but I don't read that list). Philipp von Weitershausen wrote: > (Also CCing zope3-dev where the first known working set discussion > started a while ago) > > Tres Seaver wrote: >> This is the "known good" problem. I'm pretty convinced that adding some >> kind of "PyPI subset", where gardeners for a given "package set" keep >> the list of packages / versions known to work well together, is the only >> way out of this issue. E.g., a URL like: >> >> http://pypi.python.org/pypi/release/zope3.4 >> >> would be usable as an 'index-url' for setuptools: when used this way, >> setuptools would only find / install eggs from the "gardened" set, >> rather than whatever anyone happened to have uploaded that day. >> >> If PyPI can't be tweaked to provide such a feature, we may need to come >> up with some kind of mirroring scheme which does allow it. > > This is certainly an interesting approach. I'd be curious how you would > garden this known working set. Martijn makes a pretty good case for > maintaining such working sets close to the package in question (e.g. the > grok egg, the Plone egg, etc.). I would argue that this problem is too big for "developer convenience" to drive it: we need concerted effort from the different "communities of interest" to manage the problem, in much the same way that Debian / Fedora etc. manage their various distribution releases. I see a PyPI subset implemented as follows: - Subset creator / owner defines the list of PyPI project names which are included in the subset. - For each project, the available releases known to PyPI fall into one of the following states: o 'unknown' is the default: newly-uploaded distributions start here. o 'known_good' is a terminal state: the creator / owner of the subset has blessed this version. o 'known_bad' is also a terminal state: this version won't *ever* be compatible with the others in the subset. - Other users should be able to report "works for me" / "broken" against a given distribution *for that subset.* Perhaps we can set up an RSS feed for each subset showning the "unknown" packages, so that people know they need testing. - Note that it would be possible (assuming setuptools requirements specs are sufficiently flexible) to generate a meta-egg from the "known_good" distribution list: such an egg's 'install_requires' would need to list the "known_good" values, rather than attempting to do range arithmetic. - The subset homepage would be usable as 'index_url' for setuptools, so that folks wanting to 'easy_install' a package (or drive buildout) could restrict the available packages to the "known good" versions. > I see two more solutions: > > * A versions.cfg that's loaded via HTTP. zc.buildout actually supports > this now which makes it quite appealing. Also, far as I know, all major > deployers of Zope3 that use zc.buildout for deployment use this form of > pinning egg versions right now, which means it's actually being used out > there. Locking down the file doesn't solve the problem of knowing that there are new candidate / "unknown" distributions which need testing, nor of colleting the "works for me" / "broken" information from users. A subset could certainly generate such a view, however, which would make zc.buildout integration work on a par with the 'easy_install --index-url" usecase. > * Adding version conflict resolution to zc.buildout and/or setuptools. > That way you could create meta eggs (e.g. the 'Zope' egg) with '==' > version specificers (for Grok, the 'grok' egg would function as the meta > egg as well). If this would cause version conflicts (and they often > occur in buildout due to the lack of a full dependency tree before > download), it should be possible to say which egg's versions are > authoritative. As with an apt / yum repository, a subset could harvest and export the full dependency graph information for all included distributions, assuming that setuptools was willing to use such information rather than incrementally discovering dependencies after download. I'm not sure there is much point in trying to compute such a "pickle" across the whole of PyPI, however. Tres. - -- === Tres Seaver +1
[Zope3-dev] Re: Proposal, free views
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lennart Regebro wrote: > On 9/23/07, Roger Ineichen <[EMAIL PROTECTED]> wrote: >> Heads up, >> >> Please review this proposal. > > OK. I have to admit that I don't fully understand it. > >> This proposal describes a way to make the usage of such built in views >> optional. > > "Such built in views" means what? "Optional" how? And why? > > "The additional component.zcml could be used to include only component > related configuration whitout the view parts defined in the > browser.zcml. Because the browser.zcml get's included from the > configure.zcml but not from the component.zcml" > > OK, I understand what you want to do: Start the practice of having > views in one zcml and components in another, so you can include only > the component one if so desired. I don't understand why, though. > > "Right now it's not possible to use another layout pattern without to > support zmi_views and zmi_action and it's menut item pattern. The > views defined in all packages also require the use-macro, fill-slot > pattern which is not what we allways whant. Right now there is no > option to get rid of this patterns except to duplicate packages and > replace existing views." > > That's what you will have to do anyway. Because if you don't include > the views, you will have to replace them in another package. And you > can override them in another package already... You can override, but you can't "subtract" them. Breaking the configurations out into separate pieces allows finer-grained reuse. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG9/Za+gerLs4ltQ4RAvMHAJ9ebBqY5zjdlYv7NC9kbGPSibhlfQCgjfd+ hosY5niF+q/+4lviLOytw3E= =RO+H -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: z3c.widget not on pypi?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stefan H. Holek wrote: > On 19. Sep 2007, at 00:46, Jodok Batlogg wrote: > >> i'm wondering why i couldn't fine zope.app.wsgi = >> 3.4.0b1dev_r75415 after 3.4.0 was released a few days ago. >> probably someone in [philikon, ctheune, J1m, baijum] removed the egg? >> we nailed the version to 3.4.0b1dev_r75415 (and i have still this >> egg in my cache), but it disappeared from the rest of the world. >> this should never happen for released eggs, they should be >> considered read-only imho. > > +1 > > Eggs must not disappear, ever. Now that we have decided on eggs we > have to live with the implications. This is one of them. - -1. Another implication: eggs which have '-r[0-9]+' in them should *never* be released to any location where they might be found by anyone not explicitly requesting them. Specifically, this means the cheeseshop as well as any public 'find-links' or 'index-url' location. Nobody should ever "nail" a dependency to such an egg without taking responsibility for hosting it themselves. Frankly, anybody who *wants* such an egg should instead be using a checkput + 'setup.py develop', instead; anything else is an invitation to disaster. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG8TBp+gerLs4ltQ4RAlxoAJ41h/M0PctfXgYgYm4xZu7S0RbyaACg0pS+ cxk8UG6sOYV1k+x4QZ7X29E= =zhef -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: What does python 3000 mean for zope?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lennart Regebro wrote: > A bit late post, but here is my thoughts on the subject. > > As it looks right now, It will be virtually impossible to write code > that works under both Python 3.0 and Python 2.x. This has a huge > impact on Zope, because Zope as a framework does not only have a huge > codebase in itself, but an even huger codebase of third-party > products. > > If it isn't possible to write code that works under both 2.x and 3.0, > that means that all of the codebase must be moved simulatneously. Even > if we made a version of Zope that works under Python 3, most > third-party product would not run under Python 3. > > In effect, if we port Zope to Python 3, we then have *four* > incompatible code bases. Zope 2 for Python 2 and Zope 2 for Python 3 > and Zope 3 for Python 2 and Zope 3 for Python 3. > > This is not only completely unmaintainable, it's never going to > happen. I can possibly see Zope 3 moving to Python 3, the Zope 3 > community is still small enough and well organized and tight enough > for this to work. But it has to be pointed out that any Zope 3 module > that isn't also ported will be unusable. > > I do not see how Zope 2 will ever be ported to Python 3, because doing > so would break all the thousands of third-part products out that that > doesn't get ported at the same time. This of course means that Plone > will never get ported to Python 3. Which in fact means that one of the > most successful and biggest users of Python will never move to Python > 3. And it also means that anybody that is today using Zope 3 and > hoping for The plone.* modules to continue to contribute to Zope 3, > will see that effort virtually die if we port Zope 3 to Python 3. > > I'm hoping that Guido will see the errors of his ways, and introduce a > Python 2.7 that has more forwards compatibility than what has been > promised for 2.6, so that there can be a useable overlap between > Python 2.7 and 3.0. Maybe a 3.1 with some more backwards compatibility > will be needed to, I don't know. > > Just my 2 cents. Amen, brother. "From you lips to [Guido's] ears." Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG5U5p+gerLs4ltQ4RAmKCAJwPPltvOSMbmZu7taNnL+rrK40tJQCgyNP4 eGklSY8T2i7gAg2v4kAu7Ok= =Njh5 -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: Known working sets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: > On Sep 6, 2007, at 4:02 AM, Chris Withers wrote: > >> Martin Aspeli wrote: >>>>>> Jim Fulton wrote: >>>>>>> I'm very much against making setuptools *more* complicated >>>>>>> than it already is. >>>>>> Indeed, but surely managing "known good" sets of components >>>>>> comes under its remit of version management? >>>>> Sure. It does this via requirements. >>>> Ok, forgive me for being dumb then, but why are we looking to add >>>> similar to zc.buildout? >>> We're talking more about a general pattern in zc.buildout. The >>> deficiencies of using setup.py for this alone are described well >>> in the original proposal. >> Yup, and this was the reason for my original question to Jim: why >> do something in zc.buildout rather than fixing the problems with >> setuptools? > > Because neither the problem nor the fix are well understood, imo, and > setuptools is already too complicated. > > Perhaps the same could be said about buildout, but no new buildout > features are needed to experiment with the issue at this point. If we treat the "subset" as a catalog-side problem, then we don't need to change setuptools either: we can just use 'index-url' to point at the root of the subset. Perhaps PyPI can be extended to allow "tag clouds", with sub-pages which select only packages / releases matching a given tag. E.g., I just created a small "subset" page to test this out: $ bin/easy_install --index-url=http://palladion.com/static/kgtest/ \ zope.testing Searching for zope.testing Reading http://palladion.com/static/kgtest/zope.testing/ Reading http://palladion.com/static/kgtest/zope.testing/3.4 Reading http://palladion.com/static/kgtest/zope.testing/3.0 Best match: zope.testing 3.4 Downloading \ http://pypi.python.org/packages/source/z/zope.testing/zope.testing-3.4.tar.gz#md5=5dbfed50da0169daff042da56f9bc439 Processing zope.testing-3.4.tar.gz Running zope.testing-3.4/setup.py -q bdist_egg --dist-dir \ /tmp/easy_install-kef7dg/zope.testing-3.4/egg-dist-tmp-EctfIO Adding zope.testing 3.4 to easy-install.pth file Installed \ /home/tseaver/tmp/foo/lib/python2.4/site-packages/zope.testing-3.4-py2.4.egg Processing dependencies for zope.testing Finished processing dependencies for zope.testing Another alternative would be to maintain the "subset" pages in SVN (perhaps with utilities for generating them from a manifest). Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG4BzH+gerLs4ltQ4RAuKGAJ9aB11PhcrB4uY/FQZTysyafr7z3QCfW78s AuLVzxJ8DZ+xh/KiS5dnbro= =Z4yF -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: Known working sets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: > On 4 Sep 2007, at 20:07 , Tres Seaver wrote: >> Perhaps we need to think of the "known good" set as a "PyPI subset", >> which is maintained in the same way that the various Debian distro >> lists >> are: they may end up pulling packages from the same "pool", but they >> don't expose versions / packages which have not been "opted in" to >> the set. > > That seems to suggest you would put the definition of the working set > in the hands of the package index. In other words, give setuptools or > zc.buildout a "stripped down" view of PyPI in which only the working > set shows up. > > The question is how to maintain this. You'd really want to maintain > this within an egg. So PyPI would have to expose the dependency > information (I don't know if it does that over the XMLRPC API) so > that you could build the working set information from that. I don't care whether it is in an egg, or just in a manifest which drives a script which updates the subset page. > The advantage of such an approach would be that it would work with > existing tools. Setuptools already supports the possibity of overriding the 'index_url'; maybe the "meta" egg would just override that to point to the subset page. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG3bof+gerLs4ltQ4RAnV9AJ0aQsqKShhXb1wO6Fga3erPKK2z5ACdGX1a ZzmOrN6isEFRCtShb1EXd5o= =R3YU -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: Known working sets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dieter Maurer wrote: > Wichert Akkerman wrote at 2007-9-4 09:12 +0200: >> ... >> Linux distros take an approach that does not fit in the python world >> though: their meta-set is a release with its own package database. In >> other words every distribution/meta-set has its own PyPI instance database. > > Not sure that I understand this correctly. > > If I do, then focus on a single distribution, e.g. "Debian edge". > This should be similar to the one "PyPI" database. > > Now, consider a ".deb" package, similar to one in the "Debian" distro > but not identical. > > I assume that is about Tres szenario... Perhaps we need to think of the "known good" set as a "PyPI subset", which is maintained in the same way that the various Debian distro lists are: they may end up pulling packages from the same "pool", but they don't expose versions / packages which have not been "opted in" to the set. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG3Z7u+gerLs4ltQ4RAk6GAJ9A9RjMrUvylKGzJjezDuPa+u6SagCgjwXE u4GRIDX7tI5HnM8Q5utvRJU= =qi21 -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: broken zope.lifecycleevent 3.4.0 on cheeseshop?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Benji York wrote: > Jim Fulton wrote: >> I like distribution as a place to put packages that aren't ready for >> PyPI. Unfortunately, we've put a lot of packages in PyPI that aren't >> ready IMO. > > I suggest we put them in PyPI earlier and use "Development Status :: 2 - > Pre-Alpha". Of course, we don't want to spam PyPI with /too/ many > uncooked packages. - -1. I'd rather not see *any* precooked packages in PyPI at all. People who want to share bleeding-edge packages among themselves can use some other mechanism (SVN + 'setup.py develop', for preference). Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG3Z5++gerLs4ltQ4RAqmmAKC+wHW7RFDIR8T9Xib5scneXYqQaACdEMU7 gsQ6kSAC28nwiGECKTNe9Ew= =kvnI -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: Known working sets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: > On 4 Sep 2007, at 01:21 , Tres Seaver wrote: >> Philipp von Weitershausen wrote: >>> Wichert Akkerman wrote: >>>>> The only problem is that distributing grok-0.11.cfg is a bit >>>>> tedious. >>>>> How about if buildout could get it from the web? >>>> How about making it available from an egg, through a hook in egg- >>>> info >>>> perhaps? >>> This is a very good point. So good in fact that I thought of it >>> myself >>> :) I was already writing the email when your message came in. >>> >>> >>> Martijn and I discussed the known working set problem over IRC this >>> afternoon. He brought up a few good points which suggest that the >>> version data could be associated with the egg: >>> >>> The approach that I described in my original posting (and which >>> actually >>> works *today*, as I found out!) has some disadvantages. For instance, >>> the discoverability and release mechanism of the known working set >>> configuration file differs a lot from our normal packages. >>> Releasing a >>> package is a well-known routine by now. How and where would we >>> release >>> the working set configuration file? SVN? >> Why not just release a meta-egg with hard-wired dependencies, plus the >> scripts required to set up and run the application? If the other >> components are as relaxed as possible about their dependencies, >> then it >> shouldn't matter that the meta-egg nails them down: it isn't going to >> be possilbe to re-use the meta-egg anyway (and I for one wouldn't want >> to -- I'd be creating a new environment to run it in). > > I think the use case of being able to override a particular version > of a package is valid. Let's say I'm on Zope 3.5.0 (meta egg or > whatever) and I'd like to get the newest ZODB because it has a really > cool feature. Sure, the warranty is void now, but I'd still like to > be able to do it *without* having to reproduce all the version > dependencies that the meta egg specifies. > >>> Another problem are dependencies and how we'd like to depend on other >>> working sets. Let's say we made a 'Zope' working set that >>> contained the >>> stable versions of the zope.* packages. It would make sense for >>> grok to >>> depend on this information. And packages using grok should depend on >>> that. It'll be complicated to maintain such a chain in separate text >>> files, especially across version updates. It only seems natural to >>> use >>> the egg dependency mechanism for this. >> Depending on another WS would basically Just Work (TM) if we used egg >> dependencies. > > It would, but setuptools doesn't allow us to specify "overrides" in > case of version conflicts. Perhaps zc.buildout could be taught how. > Then I suppose I could settle for using '==' in a meta egg's setup.py. > >>> When EGG-INFO is written, a custom writer will then take this >>> information and generate 'known_working_versions.txt' or whatever in >>> EGG-INFO. The only problem is that this custom writer needs to be >>> installed when setup.py is called to create egg, in other words to >>> generate the right kind of eggs you'd need to have something >>> installed >>> first. Not sure if this is better than maintaining .egg-info >>> directories >>> in SVN... >> I guess I don't get the usecase for maintaining "known good" >> dependencies outside of setup.py (for the "meta" egg). > > I don't mind maintaining them in setup.py, but the "install_requires" > mechanism is insufficient. Sooner or later you're going to end up > with a version conflict. This is definitely a case where looking at how the Linux distros packaging works is instructive: if you want to modify a package's dependencies (your overried, in this case), then you need to roll a new package. At that point, perhaps we need a tool which introspects a "base" egg's dependencies and creates a new set, overriding only what is different: in this case, the new egg would not depend on the old (in fact, it should *conflict with* or *replace* it). Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG3Ju4+gerLs4ltQ4RAmy0AJ4h8P9yQeRKqG7Qm3iuGN7e93yQrwCgkdOn PPe8f3YxJES0gbYG60/NqhI= =SIBv -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: Known working sets
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp von Weitershausen wrote:
> Wichert Akkerman wrote:
>>> The only problem is that distributing grok-0.11.cfg is a bit tedious.
>>> How about if buildout could get it from the web?
>> How about making it available from an egg, through a hook in egg-info
>> perhaps?
>
> This is a very good point. So good in fact that I thought of it myself
> :) I was already writing the email when your message came in.
>
>
> Martijn and I discussed the known working set problem over IRC this
> afternoon. He brought up a few good points which suggest that the
> version data could be associated with the egg:
>
> The approach that I described in my original posting (and which actually
> works *today*, as I found out!) has some disadvantages. For instance,
> the discoverability and release mechanism of the known working set
> configuration file differs a lot from our normal packages. Releasing a
> package is a well-known routine by now. How and where would we release
> the working set configuration file? SVN?
Why not just release a meta-egg with hard-wired dependencies, plus the
scripts required to set up and run the application? If the other
components are as relaxed as possible about their dependencies, then it
shouldn't matter that the meta-egg nails them down: it isn't going to
be possilbe to re-use the meta-egg anyway (and I for one wouldn't want
to -- I'd be creating a new environment to run it in).
> Another problem are dependencies and how we'd like to depend on other
> working sets. Let's say we made a 'Zope' working set that contained the
> stable versions of the zope.* packages. It would make sense for grok to
> depend on this information. And packages using grok should depend on
> that. It'll be complicated to maintain such a chain in separate text
> files, especially across version updates. It only seems natural to use
> the egg dependency mechanism for this.
Depending on another WS would basically Just Work (TM) if we used egg
dependencies.
> So, a possible solution is to associate the known working version info
> with an egg. More to the point, an egg could -- in addition to simply
> listing the names of its dependencies -- also specify which versions of
> those eggs it works best with. Wichert and I suggest that this could be
> put in a file in the EGG-INFO directory.
>
> The only problem is that we usually don't version control egg-info
> directories. That means the information needs to be contained or at
> least referenced in setup.py and then written upon "setup.py egg_info".
> Here's what setup.py *could* look like::
>
>known_working_versions = {
> 'ZODB3': '3.8.0',
> 'zope.component': 3.4.0,
> ...
>}
>
>setup(
>name='grok',
>version='0.11',
>...
>install_requires=known_working_versions.keys(),
>known_working_versions=known_working_versions
>)
>
> When EGG-INFO is written, a custom writer will then take this
> information and generate 'known_working_versions.txt' or whatever in
> EGG-INFO. The only problem is that this custom writer needs to be
> installed when setup.py is called to create egg, in other words to
> generate the right kind of eggs you'd need to have something installed
> first. Not sure if this is better than maintaining .egg-info directories
> in SVN...
I guess I don't get the usecase for maintaining "known good"
dependencies outside of setup.py (for the "meta" egg).
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFG3Jb6+gerLs4ltQ4RAsnCAJ4gVDaVp3Q23zERjzexEVjDgYjf6gCfecSv
sf4f3BZxwVvqxgJ4FASX+3w=
=O0Ea
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: What does python 3000 mean for zope?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: > Philipp von Weitershausen wrote: >>> The ExtensionClass changes are not done, >>> and I think there are other C-level changes which have not >> It was never said whether Zope 2 would be part of the GSoC project or >> not. That said, we can't drop Python 2.4 support until > > ... we've made sure Zope 2 runs on Python 2.5... How are you getting ExtensionClass working? Last I looked, the C extension didn't compile on 2.5. Tres. - -- ======= Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG3EsL+gerLs4ltQ4RAh4rAJwOs+TW/hE3hDHlHCsoRdbF6fjCZgCdGuAa XiTlXGUUiUaP49CA8zMyFb0= =lyAY -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: What does python 3000 mean for zope?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 nikhil wrote: > Hi, > >> Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: >> He ported the Zope 3 libraries (zope.*). He also worked on the ZODB ina >> a branch, but I see no sign of its merging. When compiling the ZODB with >> Python 2.5, I still get loads of compiler warnings. > > I started working in ZODB initially. But that time Jim was working > on the 3.8 branch. He noticed my branch and started working on > Python2.5 support to his branch. We had a discussion on this, in > which I also asked about using conditional compilation of C code > to ensure backward compatibility. He replied that it can be left for > later consideration and its better to leave the warnings as it is for > now. So as he also told that he will be looking the two remaining > test failures, I deleted my branch without merging. OK, cool. Sorry I misrepresented your work. >> Especially the difficult part, the untrusted code stuff in Zope 2, >> hasn't been tackled at all. > > At present the tests are passing for RestrictedPython( for Zope2 > also). Excellent, I didn't know that. > Also I have been analyzing the new language features added and is > trying to add new tests for checking this. But I haven't yet found any > that will compromise the security and also I think the present tests > mostly covers these. Please correct me if I am wrong. This is the trickiest part of the task: I'm glad you've got at least part of it done. Did you note which language features you reviewed, and what your thoughts were, in the code or online somewhere? That will make it easier for those of us who have worked security analysis a bunch. > Now as far as Zope2 is considered, although not a part of my project > I will be looking into that too. But as far as I looked, it may > require > unavoidable C code changes and I would like to know the general > opinion on conditional compilation (if no other option is present). I'm pretty sure conditional compilation is going to be required, because object laysut changed in incompatible ways. We might be able to confine most of that to a couple of macro definitions, though. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG3Erj+gerLs4ltQ4RApodAJ47E8SJODCmGzPLvNm1ThjQUIDs8wCfS/Wi 1T0ja5VN+VaZdSmMXhTcne0= =Izf8 -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: What does python 3000 mean for zope?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: > Hey, > > David Pratt wrote: >> Ultimately, the >> folks that will even want to maintain a 2.x code base will quickly erode >> since the forefront of development is never the past. Perhaps it will >> all move more quickly for this reason when python 3K is out for real. > > This is what I fear will happen. This could mean either some huge > codebases in Python 2.x are going to be left behind in some kind of > ghetto, or that the single community will fracture into a Python 2.x and > a Python 3.x community. Both scenarios suck, so I certainly hope I'm > being pessimistic about this. I don't think so. I think the second one is already reality. I see zero benefit to moving to Py3K for any work I'm doing, and active damage from trying to do so in Zope. Tres. - -- ======= Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG2vt6+gerLs4ltQ4RAlgjAKDdV4hL61lGFPEueXLWDREj18QllQCgh4hA xaKMZUe0JFEq9/CZGAOzZ6s= =KsjU -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: What does python 3000 mean for zope?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Baiju M wrote: > Philipp von Weitershausen wrote: >> David Pratt wrote: >>> Hi. I am concerned about the announcement of python 3000 today that >>> will break backwards compatibility. Zope and twisted are my >>> favorite frameworks. The code base for both frameworks are not >>> small. I haven't evaluated the changes but I can say this is a not >>> great day for the python community either. I can see this dividing >>> folks between present and future. >>> >>> Particularly, I'm thinking about incompatibilities developing >>> around packages and dependencies through some sort of drawn out >>> transition by the python community that may take years. Has anyone >>> thoughts or comments about python 3000 implications for zope? >>> Unfortunately, my first thoughts are that Python 3000 feels like >>> Y2K for python :-(. Many thanks. >> We're currently struggling to get to Python 2.5 (which isn't exactly >> fresh out of the oven) mostly due to incompatibilities that it >> introduced compared to Python 2.4. So when Guido says Py3k will allow >> incompatible changes for the "first time", it'll be hard to imagine >> how big the implications really are. It's especially hard to imagine >> because Py3k isn't done yet. Will the stdlib be reorganized? Who >> knows. I sure would like to see this '2to3' tool tackle the Zope >> codebase. C extensions, anyone? > > In fact Python 2.5 porting was not as much difficult as predicted in an > old thread [1]. It isn't done yet, so I'm not sure what you are talking about. > Nikhil has completed porting to Python 2.5 as part of Google Summer of > Code project [2]. He ported *ZODB*, not Zope. The ExtensionClass changes are not done, and I think there are other C-level changes which have not > But we cannot officially support Python 2.5 until Zope 2 is also ported. > (This is a policy of Zope Foundation, I guess) > But we can give support for individual packages, is it ? > > May be we can try Python 3.0 porting in next GSoC ? :) Frankly, I'm uninterested in spending *any* effort on Py3K support: we'd be more likely to get traction out of Jython / IronPython (which are alreday stable, and run on platforms we don't yet support). Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG2vsG+gerLs4ltQ4RAn1EAKCGpD38CFG4DPeJPNGcp1oHKqDviACgkmN1 l2rvqr8dBAbCyCqPwc9oEEI= =fA5F -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: Guide for maintaining software in the Zope repository
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: > We have 100+ packages that make up what used to be distributed as > "Zope3". We have numerous more packages in svn.zope.org. Most of them > are developed, released and distributed individually. We like to think > this is a good thing (I certainly do). But currently we have a bit of a > chaos [2]. It's not bad, but I fear without some guidance, it'll get worse. > > Christian Theune recently wrote a document [1] in which he outlined how > we should get to a development process and what topics it should touch. > This document is very hands-on and describes actions that should be > taken to reach these goals. I've taken the liberty to jump ahead and > write down some current practices: > > http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/maintaining-software.txt Thanks for drafting this document. A couple of comments (mostly niggles). - At then end of the last summary bullet under "Repository layout", you say, "Release tags shouldn't be committed to." I would say that is true *after* the release is announced. Sometimes it may be more convenient to modify the tagged code during the process of making the release (see below). - The changelog should include dates for each release, formatted consistently (ISO short form is likely best, as it is unambiguous). - Under "Releasing Software", you specify what is to me a controversial rule: "Increase the version number (in ``setup.py`` and elsewhere) on the trunk or the release branch to the *next* release." While I realize that many projects are doing this, I don't like it: I prefer that the trunk changelog contain an "unreleased" section for features / changes not tracked on the current release branch. In particular, I don't want to make it easy for somebody with a trunk or branch checkout to create a pseudo-release egg. In this case, "speed kills", because sloppy release making punishes everybody downstream. I would therefore advocate keeping the 'version' tag on the trunk to something containing 'trunk' or 'unreleased'. Release branches should contain 'branch' in their version, except immediately before copying to a release tag. As an alternative (see above), copy the release tag and then change the version there. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG0FPk+gerLs4ltQ4RAgn7AJ9BG0hcMn+cBkx6+1qW4bIeurlJQgCfa1l7 lVrgMfItaGX44N1fUBKBZwQ= =xvIa -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: Guide for maintaining software in the Zope repository
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: > On 24 Aug 2007, at 18:55 , Fred Drake wrote: >> I don't really care whether the style is the "classic" Zope 3 style or >> PEP 8, as long as it never changes. > > With this you seem to suggest we should continue using the "classic" > Zope 3 style. - -1 to PEP8 (which is *not* universal in the Python community, as Fred pointed out; in particular, it makes choices which seem more appropriate to single-module code than namespaced-packages) +1 to Zope3 (and note that I have alreay moved there myself). That style is already documented; we should not need to expend any significant effort maintaining it. Tres. - -- ======= Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG0FA4+gerLs4ltQ4RArnIAJ9UuaJISJCj81MTlBqlButvhJrnfACfeC+M 3KLIrSwi6hIOE0a7e6Ky2lM= =fC8y -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Backward compatibility and major releases (series) update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Theune wrote: > Am Mittwoch, den 22.08.2007, 16:15 -0400 schrieb Tres Seaver: >>> I eventually came to the conclusion that our original conclusion was >>> sound, but that we should only introduce backward incompatibilities >>> when the need is very dire, as it will cause lots of pain. > > +1 from me as well. > >> +1. Cleanliness is not a good enough reason to break a public API, >> for instance. If necessary, the incompatible stuff might be better >> off moving to a new package / API name altogether, with the old name >> left as a pure compatibility shim (perhaps wich "evergreen" deprecation >> warnings). > > By that you mean that we put deprecation warnings in place and tell > people where to find the new stuff without the time-pressure notices > like "will go away when you don't look"? :) Right. I don't think removing public APIs is useful, for the reasons Jim was outlining: the chance of breaking unknown dependents is not worth the cleanup (e.g., zLOG). Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGzbbF+gerLs4ltQ4RAteVAJ9YixyG+ailwiR+Cio7s/KOL2eQEQCeNc7u wO35gklD3SA2N+OKFYv+/Ws= =fQth -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Backward compatibility and major releases (series) update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: > A while ago, we had a discussion about backward compatibility and > decided that only major releases should be backward compatible. So, > for example, a 1.2 release should be backward compatible with a 1.1 > release, but a 2 release could be backward incompatible with a 1 > release. We then said we wanted a nice way to spell depending on a > major release. (The current way to spell depending on a major > release is "foo >=R.dev is the major release number.) > > We recently had an opportunity to experience this with > zc.relationship. zc.relationship 2 was released and some packages > were updated to require zc.relationship 1. Unfortunately, not all of > the packages we use were updated and this caused version conflict > errors. (This was partly a result of setuptools weak conflict > resolution algorithm.) My initial response was, "oh, we need to > update all of the other packages that depend on zc.relationship to > require version 1." But then I started wondering how we would > migrate to version 2 and realized that it was going to be rather > hard. All of the dependent packages would have to move in lock step > and we'd be back to a monolith. This was enough to make me think > that backward incompatible changes are just untenable. I gave a hint > to this in some later email threads. > > Since then, I've looked at a number of packages that we've split out > from Zope that have excessive dependencies. zope.component is a > great example. The excessive dependencies (at least the hard ones to > deal with) are a result of poor factoring of functionality at a time > when dependencies didn't matter. Unfortunately, I think the only way > to fix some of these is to split off functionality, which will > introduce backward incompatibility. > > I eventually came to the conclusion that our original conclusion was > sound, but that we should only introduce backward incompatibilities > when the need is very dire, as it will cause lots of pain. +1. Cleanliness is not a good enough reason to break a public API, for instance. If necessary, the incompatible stuff might be better off moving to a new package / API name altogether, with the old name left as a pure compatibility shim (perhaps wich "evergreen" deprecation warnings). Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGzJld+gerLs4ltQ4RAjDFAKCcf9tlJhiSM+7VPkH1QmnJx/YGHQCdEOyN hyuU4a1s+apbrtT1mDh4hgE= =suL+ -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: We should be able to stop unhiding PyPI releases.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: > As of Monday's zc.buildout release, buildout now uses the simple > package index: > >http://cheeseshop.python.org/simple > > by default. (You can cause it to use another index by setting the > buildout index option.) > > This change should provide significantly better performance and will > make it easier to use historical releases, because the simple > interfaces shows releases that have been hidden from the human > interface. > > Normally, when new releases are registered with PyPI, old releases > are hidden. This has been a problem for buildouts or application > packages that fix package versions, because hidden releases weren't > visible to setuptools. To get around this, we had to unhide old > releases, which was a pain. The simple package index shows all > releases, including hidden ones. Now that buildout uses the simple > index by default, hidden packages should no longer be a problem, at > least for buildout users. People using easy_install can configure it > to use the simple index. They might want to lobby to have > easy_install use the simple index by default. > > If there are no strong objections, I plan to stop unhiding old releases. I would argue that hiding old releases is a major misfeature of PyPI, personally: humans probably have as much to gain from seeing the older versions as scripts. Even "brown bag" releases should remain available (albeit, with perhaps some way to tag them as problematic). Releasing a software package is a contract which implies more than "flavor of the week" status, at least in lots of circles. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGzE1K+gerLs4ltQ4RAuEMAJ95udSCyp96xMbr11/vUYCHzfqNzQCeMmLh bU86z/gCwyN04WgOv4PsTrE= =BLBZ -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Add function for schema validation in zope.schema
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Wichert Akkerman wrote:
> Previously Christian Theune wrote:
>> Hi,
>>
>> Am Montag, den 20.08.2007, 08:59 -0400 schrieb Fred Drake:
>>> On 8/20/07, Christian Zagrodnick <[EMAIL PROTECTED]> wrote:
>>>> I think we should add a function to validate a given schema on a given
>>>> class. This should include constraints and invariants:
>>> I do presume you mean object, rather than class, as your example implies.
>>>
>>>> validateSchema(IMySchema, myobject) [or alike]
>>> +1
>>>
>>>> I'm not sure about return values or exceptions. There are different use
>>>> cases:
>>>>
>>>> 1. Is the object valid? -> True/False
>>>> 2. What's wrong with the object -> {attribute/field-name: what's
>>>> wrong}, what's wrong with invariants.
>>> There should probably be a specific exception that's defined for this
>>> purpose, and it could directly support the mapping interface to allow
>>> detailed information to be extracted. I suspect a common use would be
>>> to simply verify the object and raise the exception in the invalid
>>> case, denying whatever operation was being attempted.
>>>
>>> This also suggests that there's no interesting return value; either
>>> the exception is raised or it isn't. Code that wants to introspect
>>> the exception can catch that and act accordingly.
>> >From my latest experience and research of when to use exceptions and
>> when to use return values I'd say let's not use an exception.
>>
>> The report of "which fields are wrong" is the normal result of this
>> function. Invalid data is not an uncommon output, rather, it's the sole
>> purpose of this function. An exception should be raised if the
>> validation could not be performed.
>>
>> The result could be a structure that lists all errors. Eventually a
>> result that equals False could be used to signal no errors, e.g. an
>> empty dict or an empty list.
>
> That would be confusing though: I would expect the result of a method
> that checks validaty to return something that evaluates to True if
> everything is valid. Code like this just messes up my brain:
>
> if not zope.schema.validate(obj, IMySchema):
> print "Everything validates correctly!"
>
> to me that is very non-intuitive and looks like the if condition is
> incorrect.
Returning boolean discards the information which only this function
should know, and which the caller (potentially) needs: the list of
errors. The name 'validate' doesn't imply a boolean return to me at
all. I would expect to see it used as follows::
errors = zope.schema.validate(obj, IMySchema)
if not errors:
print 'OK
else:
print 'Errors: \n%s' % '\n'.join([str(x) for x in errors])
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGyaBB+gerLs4ltQ4RAjDQAJ9e1gY/MxrAF7dOpTcATtQPjLAQ7gCgqy4X
2QztzPecPxDIKEqfvJUr0AI=
=IxRz
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Add function for schema validation in zope.schema
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Fred Drake wrote:
> On 8/20/07, Christian Zagrodnick <[EMAIL PROTECTED]> wrote:
>> I think we should add a function to validate a given schema on a given
>> class. This should include constraints and invariants:
>
> I do presume you mean object, rather than class, as your example implies.
>
>> validateSchema(IMySchema, myobject) [or alike]
>
> +1
>
>> I'm not sure about return values or exceptions. There are different use
>> cases:
>>
>> 1. Is the object valid? -> True/False
>> 2. What's wrong with the object -> {attribute/field-name: what's
>> wrong}, what's wrong with invariants.
>
> There should probably be a specific exception that's defined for this
> purpose, and it could directly support the mapping interface to allow
> detailed information to be extracted. I suspect a common use would be
> to simply verify the object and raise the exception in the invalid
> case, denying whatever operation was being attempted.
>
> This also suggests that there's no interesting return value; either
> the exception is raised or it isn't. Code that wants to introspect
> the exception can catch that and act accordingly.
- -1. Detecting the schema violation is "mechanism", raising an
exception is "policy"; they shouldn't be mixed here. Let the caller
raise an exception if that is appropriate
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGyZ9V+gerLs4ltQ4RAvEkAJwKK50BjjTwzNE39gsw1nXXq+JNVACcDKWK
2jxn+16Ax1Lx2sXf6vAy2EM=
=Y25B
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Removed zope.security 3.4b4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: > Christian Theune wrote: >> Hey, >> >> Am Mittwoch, den 15.08.2007, 14:15 +0200 schrieb Christian Theune: >>> Hi, >>> >>> I saw the error reports about zope.security and got talked to from a few >>> people that they had severe problems managing around this. I removed the >>> 3.4b4 distribution from download.zope.org to allow them to continue >>> using zopeproject and grokproject until we find a fix. >>> >>> I wasn't sure about that, so if someone has even worse problems now, >>> please speak up and I'll put the package back into place again. I hope I >>> didn't cause any more problems than exist already. >> Ok. As this affected more packages and Wichert found out how to deal >> with this in the buildout.cfg of grokproject (zopeproject and other >> buildout-based projects should be able to derive a workaround for this >> until it's fixed.) >> >> See http://paste.plone.org/16261 for the full buildout.cfg. The most >> important lines are 11 to 15: >> >> [app] >> recipe = zc.zope3recipes>=0.5.3:application >> eggs = >> test >> zope.security==3.4.0b2 > > Does this mean the package won't get removed? I just prefer to use a > situation where I don't get the broken egg in the first place. You're hosed, then: people are going to release eggs which break "downstream" applications (think libs in Debian unstable). Until we segreate the "known good" set away from the "I just did something cool, please test" set, this problem is unavoidable. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGxc2b+gerLs4ltQ4RAi+UAJ9YajDGGNys1SGTNrTR3lR2oH2P4ACfeydA AkQPu0h7o0NtGAN1z8JlXxE= =2i0l -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Dependency cleanup: zope.traversing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: > On Wednesday 15 August 2007 08:01, Christian Theune wrote: >> zope.traversing has a dependency to zope.app.applicationcontroller. This >> is because zope.traversing implements the "etc" namespace and has a hard >> coded reference to "applicationcontrol" there. >> >> In the same place it also looks up site managers (in a hard coded way). >> >> As a strategy to remove this dependency we should move the etc namespace >> to some other place in zope.app. I did not find reasonable candidates to >> move this two. Bad candidates are zope.app.publisher or >> zope.app.publication, zope.app.applicationcontrol. A new package could >> be created for the etc namespace too, but I'd like to avoid that. > > I think that zope.app.component would be a good candidate, because "etc" is > pretty much about accessing the local site. I know it was originally designed > for allowing many different non-content things to be plugged in, but this has > not materialized. > > An alternative would be to get rid of ++etc++ and implement ++site++ and > ++control++. Now that I think about it, I actually favor this. ;-) Or change zope.traversing such that it looks up namespace-based stuff via a named utility / adapter; then packages which supply a namespace are not dependencies at all. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGww/h+gerLs4ltQ4RAm0LAJ491mh0nC4XbsX/SEG+d/0VHRUhBwCgoPkp XMLdvvMdQkoL2DKDfvQXA8s= =nvgz -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: 'thread_local' AttributeError in zope.security.checker
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: > On Aug 14, 2007, at 7:32 PM, Paul Carduner wrote: > >> Hello zope3-dev, >> >> I came across an error I have not seen before. Just for reference, >> here is the last snippet from the traceback: >> >> File "/home/pcardune/Work/ZContact/zcontact-lp/eggs/tmpgwuq6O/ >> zope.security-3.4.0b4-py2.4-linux-i686.egg/zope/security/checker.py", >> line 420, in ? >> AttributeError: 'module' object has no attribute 'thread_local' > > I wish you had included the whole traceback. > > >> The interesting part to me is that it was so easy to fix. Here is a >> snippet of the relevant area of failing code from >> zope/security/checker.py >> >> # Get optimized versions >> try: >> import zope.security._zope_security_checker >> except ImportError: >> pass >> else: >> from zope.security._zope_security_checker import _checkers, >> selectChecker >> from zope.security._zope_security_checker import NoProxy, Checker >> from zope.security._zope_security_checker import _defaultChecker >> from zope.security._zope_security_checker import >> _available_by_default >> zope.interface.classImplements(Checker, INameBasedChecker) >> >> The very first import statement is throwing the error, but alas, it is >> not an ImportError. If I patch this code by catching the >> AttributeError in the same way the ImportError is caught, then >> everything works fine. > > Except you don't get the C optimizations. IOW, you would just be > covering up a real error. > > >> I tried looking into the c code, but after >> years of python development, the c code just frightens me (a bit). >> That said, I would really appreciate any pointers people might be able >> to give me on what thread_local is for and why I (don't) need it. > > I rearranged the imports in zope.security yesterday. I apparently > broke your usage, but I can't tell what your usage is. I'll need to > see the whole traceback. In particular, I'll need to see the import > order. We badly need to get a handle on how we expect people to fetch eggs for packages: having such a refactoring affect an indirect client (one not expecting to track day-to-day development) is a disaster. Dumping revision-stamped (unreleased) eggs into a directory used by unsuspecting users is a recipe for bringing *all* development to a screeching halt. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGww8E+gerLs4ltQ4RAizUAJ4/g04M14f9pI2QA/NAub2CwrVtDwCfQ2cD dQNNFuvkirf3sbAWOuC7/VE= =YjyB -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Proposal: Move ISite to zope.location was: ISite misplaced in zope.app.component.interfaces
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Howitz wrote: > Hi, > > after thinking the problem over at gocept we came to the following > suggestion: > > - A site is a place which gives acces to a component registry. > - ISite isn't a good name for the concept behind it, because it is > connected too tight to a website and on having hierarchical > structures (at least in the code). > - In long term a more abstract concept for ISite could be added. It is a "place", in the classic Zope2 sense, as implied by "placeful" / "placeless": a location-specificpolicy configuration point, which can acquire further policy configuration from "above". In Zope2, nearly every persistent object is a "place", at least for purposes of configuring security. > - In short term, for cleaning up dependencies, I propose to move > ISite to zope.location, because it is the only package outside of of > zope.app.* which uses ISite and defindes a method to get the nearest > site. We think this is the right place because ISite is about > component registries in the context of location. +1 > - zope.app.component.interfaces then can import ISite from the new > place to avoid deprectation. +1. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGww5D+gerLs4ltQ4RAsP2AJ4lN1SCb+3mhPyaWolWrXjOIwDLIQCfTpax xDIRflBduAg55RDp3axNohI= =1VKk -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: zopeproject
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lennart Regebro wrote: > On 7/19/07, Dieter Maurer <[EMAIL PROTECTED]> wrote: >> But, Zope is quite easy on entry. > > Zope2, yes. > Zope3? Not at all. > > Will modularizing Zope 3 make it easier for newbies? Not really, but > with zopeproject or similar it shouldn't be more complicated either. > In fact, the installation process might end up being simpler: > > Compare: > > wget http://www.zope.org/whatevah/Zope.tgz > tar xvfz thetgz > ./configure > make > make install > make instance directory > > With: > > easy_install zopeproject > zopeproject directory > cd directory > bin/buildout > > Or something similar to that. Doesn't really look more complicated to me. :-) > Sure, it uses paste and stuff, but you don't have to know about that to use > it. I think we need to leave soem space for people who want to customize the site, without wanting to do "full-on" Zope3 package-based development. If zopeproject makes it obvious where to put "filesystem pages", people will use them, probably. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGn86a+gerLs4ltQ4RAhhaAKCKHbmXXHyYHRrLfmNwSntE+sxrOwCeI0Mq zbxxqSUrW10QZEsfSy0/pts= =ZHFW -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Dealing with external dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: > On 19 Jul 2007, at 00:43 , Jim Fulton wrote: >> Depending on specific versions in library packages (as opposed to >> application packages or buildouts) is a recipe for disaster IMO. >> As soon as 2 packages depend on different externals, then those 2 >> packages won't be usable together. > > Good point. But not necessarily avoidable: if version 3 of library A depends on a feature provided by version 5 of library B, but version 7 of library C is incompatible with versions of library B > 4, then those versions of A and C really *are* incompatible; that isn't an accidental clash. Library authors need to *minimize* their own depdendencies if they want to maximize their library's usefulness: that means avoiding depending on newer versions of libraries without *very( strong need (degrading gracefully, if possible). Another problem: the folks who manage your dependencies may not be very good at it: - They may remove old release versions, making it impossible to satisfy your dependency. - They may *replace* a release version (even more evil than removing it). - They may screw up SVN or CVS repository history (e.g., 'svn rename' will cause even a revision-specific external / checkout to break). >> In the long run, it might be better to only reuse packages that >> offer some backward compatibility promises. Depending on a specific >> version will make the dependent packages less reusable. > > That makes sense. So, coming back to the real world: we have two > issues at hand. One is docutils, one is zope.testbrowser which > depends on mechanize and ClientForm (Adam is working on that, CCing > him as well). > > With docutils I understand that it makes much sense to do this at > application level. With mechanize and ClientForm I'm not so sure. > What I *do* know is that the current situation (packaging them > *inside* the zope.testbrowser egg) isn't ideal (same goes for > twisted, btw). That situation is a "fork", which may be the lesser of evils, depending on how things work out, especially in the face of poor upstream release hygeine. > Should the next zope.testbrowser simply depend on any version of > mechanize and ClientForm? > >>> [1] This problem has bitten us over at Grok because apparently >>> Ubuntu has decided to deploy docutils 0.4.1 which doesn't seem to >>> actually exist anywhere and therefore confuses zc.buildout. See >>> https://bugs.launchpad.net/grok/+bug/126742. >> I'm fairly sure that this has nothing to do with version numbers. >> I suspect instead that it has something to do with the fact that >> all distributions are now installed as "develop eggs" on ubuntu. >> The locations of these eggs is actually site-packages. This sounds >> very wonky to me, but Phillip Eby says it is normal. > > It's actually necessary (to install these things as eggs) because > many packages nowadays depend on entry points. One could argue, > obviously, that their location (site-packages) isn't ideal... System pythons be damned. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGn6EQ+gerLs4ltQ4RAnJpAKCRI034pHc1a7MVLzblcS9Jegpn3QCfZgoW lE838s0c37QPT7GOuXTDM0M= =OW0w -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: AW: Re: Problems with zope3 on windows
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Roger Ineichen wrote: >> -Ursprüngliche Nachricht- >> Von: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] Im >> Auftrag von Hanno Schlichting > > [...] > >> Full tracebacks are available in the thread from May/June at >> http://mail.zope.org/pipermail/zope3-dev/2007-June/022752.html >> >> The problem is still that zc.zope3recipes uses zopectl and in >> turn zdaemon which don't work on Windows. As outlined in the >> old thread this is a known problem and not that hard to fix. > > Right it uses zdaemon which doens't fit for windows. > >> Currently it justs needs someone to sit down and do the work. >> I myself won't do it, as I only use Zope 3 through Zope 2 >> where all this has already been fixed ;) > > Can you point me to the right repos/place of this allready fixed > issue in Zope2. So I can take a look at that and fix it if I find > out how this eggs work. http://svn.zope.org/Zope/?rev=75066&view=rev Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGn3aV+gerLs4ltQ4RAorJAKC+ha97jGbjdQsALG4s0WcTg10fjgCdHKvz SVXpo3mHa8tXoWt/UL1+Z5k= =9t6d -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Windows eggs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: > On Friday 13 July 2007 12:14, Jim Fulton wrote: >> IMO, a could release should have: >> >> - a good overview, and preferably >> >> - on-line documentation > > Right, I think this is well-served for packages that have doctests. I think > that your example of including the dotest files into the long description is > a good thing. However, I have noticed some problems with regard to PyPI: > > 1. It does not support unicode. I had some problems with characters before, > but I cannot remember the details. > > 2. The PyPI website does not encode the long description, causing text with > HTML to not display correctly. I have avoided this problem by escaping the > long description myself, but then you loose the REST conversion. (See > z3c.form.) > >> Of course, the standard meta data should be filed in to a reasonable >> degree. > > Okay, I think most of the packages provide a lot of the info with exception > of > the Trove classifiers. They are very important for marketing reasons, because > the PyPI Package browser (http://cheeseshop.python.org/pypi?%3Aaction=browse) > recognizes them and uses them to organize the packages. I think it would be > awesome, if it would say: "Zope 3 (300 [packages])". > > OT: Did you notice that 17 out of 20 package updates today where > Zope-related? :-) > >> Mainly what I'm looking for is a good faith effort. > > I think in the long term it will be most beneficial, if we convert all tests > to doctests; then a reasonable on-line documentation is not that hard to > provide. - -1. "Good tests" don't always make "good documentation"; I prefer the isolation of traditional unittests for anything other than "main line" use cases, for which doctests are best suited. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGl9UG+gerLs4ltQ4RAieBAJ9YFESD+JSi4d8NX+NpOEzBaOQQ8gCgy9tz fPqgeZ/Rc3V/1HFnvYFKNYk= =gi4m -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: CHANGES.txt
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gary Poster wrote: > On Jul 13, 2007, at 11:30 AM, Jim Fulton wrote: > >> On Jul 13, 2007, at 11:07 AM, Philipp von Weitershausen wrote: >> >>> Tres Seaver wrote: >>>> Doing proper release management can't reeally be called a waste >>>> of time >>>> (that would include documenting exactly what *has* changed). >>> Tres raises a good point. We should continue to maintain a >>> CHANGES.txt or a 'Changes' section in README.txt for all zope.* >>> projects now. And I would recommend that others do the same with >>> z3c.* etc. packages. >> Agreed. >> >> I recommend using a changes section in README.txt because it's >> tricky getting distutils to include other root-level files and I >> want to keep our setup scripts as simple as we can. Distutils sucks in this regard. > Hm (and sigh). I was following what I thought was another Tres > suggestion: put CHANGES.txt in the package, and a pointer in the top > level to the package's version. That is still my preference: I think a people are more likely to find a changelog that way. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGl60o+gerLs4ltQ4RAmNmAKCKQPQME/pdBN087ADCZ4suwHAHFwCgz5fi R+elhyT0jmgcJ7ZJoD00lMU= =x0f/ -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Windows eggs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: > Tres Seaver wrote: >>>> Point me at an existing source release, and I'll be happy to generate >>>> corresponding windows eggs. >>>> >>>> I made windows eggs for the latest version of zope.interface that's in >>>> pypi. >>> Great. So we have zope.interface and zope.proxy and there'll be no need >>> for zope.thread. Which leaves us with: >>> >>> http://download.zope.org/distribution/zope.security-3.4.0b2.tar.gz >>> http://download.zope.org/distribution/zope.app.container-3.5.0a1.tar.gz >>> http://download.zope.org/distribution/zope.hookable-3.4.0a1.tar.gz >>> http://download.zope.org/distribution/zope.i18nmessageid-3.4.0a1.tar.gz >> Are you asking that Windows folks run using these alphas as binaries? I >> don't quite see the benefit. > > So I guess you don't see the benefit of releasing Windows binaries for > alpha and beta releases. > >>> I realize that those aren't final releases, but they (most probably) >>> haven't changed significantly after these releases were made, which >>> would make it a waste of time if I had to tag and tarball them just for >>> the sake of a different version ID. >> Doing proper release management can't reeally be called a waste of time >> (that would include documenting exactly what *has* changed). > > Right. *Proper* release management. I believe we have a volunteer > release manager for that and for Zope 3.4 it's not me. Right: you are asking that somebody do the release manager's job, or at least part of it. I was trying to point out that doing only a partial job (making binary installers for alphas) is likely to be troublesome. Note that under our proposed release regime, depending on an alpha makes *you* and alpha, too; is that what you want? >> Again, what kind of Windows user are you expecteing (wanting) to test these >> eggs? > > People who want to try out Zope 3.4 on Windows, in particular those who > want to try out Grok, the buildout instance recipes and Zope-on-Paste on > Windows. > > We've done some Zope 3.4 alpha and beta released, why shouldn't we make > Windows eggs for those so that people can actually *try* them before a > final release? Until somebody makes a "release manager" call that a package is stable enough for beta, I'd be really reluctant to ask people to test using binaries: they won't be able to develop or apply patches to test fixes, for instance, to bugs in the C extensions. Making it easier (via documentatin, likely) for *anybody* with an appropriate toolchain to build Zope's eggs on Windows would help, both by removing the need to built them before a real release, and by getting better feedback on platform-specific problems earlier in the cycle. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGl5bv+gerLs4ltQ4RAmC5AJ9zb1Z8AZhvkD1mmsQGA4dvo9mURgCglFZB P3N0nPECSp/QrrEQ0iCffBc= =0NZ/ -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Re-revisiting IResult (for in-Zope pipelining)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gary Poster wrote: > On Jul 13, 2007, at 6:06 AM, Lennart Regebro wrote: > >> On 7/13/07, Gary Poster <[EMAIL PROTECTED]> wrote: >>>> We are looking for recommendations and visions on how to do this >>>> pipelining with IResults, because it's not entirely clear to us >>> at the >>>> moment. Main worries are the questions of how to differ between >>>> results that need to be themed and those who don't, >>> I thought you'd return different objects, and rely on adapters. I'm >>> a bit surprised at the question, actually--what have I missed? >> Well, most HTML output is done by templates, which typically return >> unicode. I guess we can let the BrowerPublication to wrap the unicode >> in an object... > > No, the intent is that this is explicit in the view. > >>>> I have earlier (before IResult being made public) made a quick hack >>>> that inserts theming earlier in the process by replacing the >>>> BrowserPublication, maybe that's a better way to put theming? >>> Doesn't appeal to me--feels like the hack that we did for >>> zc.resourcelibrary, in which the change to the system is much, much >>> too heavyweight (someday we'll convert it to using IResult, I >>> suspect)--but you're doing it. :-) >> Maybe. :-) >> But just after I pressed send I actually realized that one part of the >> theming is getting in viewlets therem which is quite difficult if you >> don't have the context, which actually again points at the Publication >> being the right place to do this. Or am I missing something? > > Here's what I was thinking. > > If you want a view to return an unprocessed unicode value (or perhaps > "lightly processed") then have it return the value. The end. The > pipeline will do little or nothing to it. (zc.resourcelibrary might > look for "HTML-ness" in the string and try to insert, but that's it). > > If you want it to be processed as part of a pipeline, then return an > object that has what you think the pipeline will need. For instance, > here's a very off-the-cuff version. There's a *lot* of room for > figuring out different ways for this to work, which is one of the > interesting bits, and why we've said, at least internally, "let a > thousand pipelines bloom"...and then presumably just a few of them > will settle down and win. You can't ask "upstream" to produce a thousand different pipelineables; the interface there needs to be dirt simple, and *always the same.*. In particular, you can't return unicode *or* a pipelineable: that puts the policy choice in the wrong place. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGl5P3+gerLs4ltQ4RAir2AJ0aVIIHgD4TsF23VA1fzsefalUV5QCfY9WM N2DuzN+/syLDKfz8YdzdYFk= =VBz5 -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Windows eggs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: > Jim Fulton wrote: >>> On Jul 13, 2007, at 6:57 AM, Jim Fulton wrote: >>> >>>>> * zope.interface >>>>> * zope.security >>>>> * zope.app.container >>>>> * zope.hookable >>>>> * zope.i18nmessageid >>>> Could you or someone else make final source releases of these first? >>>> I expect that some of these haven't changed since Zope 3.3. We should >>>> not make new releases of eggs if they haven't changed. One of the >>>> great things about eggs is that we can stop releasing non-changes. :) >>> In the short term, I'll go ahead and make windows eggs for the >>> packages that have latest source distros. >> I take that back. It looks like it's going to take more time than I >> have to figure out what releases to make. There are various versions >> floating around. > > Yes, I noticed that too. I think the current situtation is way too > confusing. We should decide which the authoritative source for the eggs > is, the CheeseShop or http://download.zope.org/distribution. The > advantage of the latter is that everybody with checkin rights can > release a new egg, whereas on the CheeseShop it takes access rights. > >> Please either: >> >> Point me at an existing source release, and I'll be happy to generate >> corresponding windows eggs. >> >> I made windows eggs for the latest version of zope.interface that's in >> pypi. > > Great. So we have zope.interface and zope.proxy and there'll be no need > for zope.thread. Which leaves us with: > > http://download.zope.org/distribution/zope.security-3.4.0b2.tar.gz > http://download.zope.org/distribution/zope.app.container-3.5.0a1.tar.gz > http://download.zope.org/distribution/zope.hookable-3.4.0a1.tar.gz > http://download.zope.org/distribution/zope.i18nmessageid-3.4.0a1.tar.gz Are you asking that Windows folks run using these alphas as binaries? I don't quite see the benefit. > I realize that those aren't final releases, but they (most probably) > haven't changed significantly after these releases were made, which > would make it a waste of time if I had to tag and tarball them just for > the sake of a different version ID. Doing proper release management can't reeally be called a waste of time (that would include documenting exactly what *has* changed). Again, what kind of Windows user are you expecteing (wanting) to test these eggs? > Thanks again > > Philipp > > > P.S.: While looking around, I found that an ancient version of > zope.security actually exists as a Win32 egg on the CheeseShop: > http://cheeseshop.python.org/pypi/zope.security/3.4dev-r73262. > I wonder why my Windows buildout didn't find it. Perhaps the egg doesn't > satisfy a version dependency? - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGl5Js+gerLs4ltQ4RAjsAAJ4+NCg81tWVOpYjK7FMM5TG6GqpGACgw3FF p6mFmmhOH+2GC+U7Ic9U6mI= =hb+y -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: How to debug zope3 if it completely hangs?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Benji York wrote: > Fabio Tranchitella wrote: >> I'd like to know if zserver is a good choice for high loads or if it >> deprecated and I should stay with twisted. > > We run some pretty high load apps, and we're happy with zserver. > >> Was zserver disabled only for security reasons? > > I don't believe it had anything to do with security. Nope: it was disabled because: - Not many people feel competent to extend ZServer. - People thought that using a server maintained by others was better than maintaining one ourselves. - Twisted offers potential features which seemed interesting at the time (I don't know how many of them actually got integrated). I prefer ZServer becuase: - It is faster. - It is less complex. - It got *lots* of attention for real-world scaling issues, and is rock-solid stable. - I don't need the extra "shiny" features. Note that the "flavor-of-the-month" is actually WSGI now, rather than Tsisted (which uses the WSGI support): see Philipp's "zope on a paste" demo, for instance. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGlkLn+gerLs4ltQ4RAog7AKCwL1HTkA5jTyaRH8KnRO0zctRyEACgqDtE WJp8yaqXzRFAf/hf6O1HNmI= =4ony -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: zope.app.session/zope.minmax
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marius Gedminas wrote: > On Wed, Jul 11, 2007 at 02:13:46PM -0400, Tres Seaver wrote: >> Fred Drake wrote: >>> On 7/11/07, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: >>>> Right, I made the same assumption: the eggs have been set free, >>> >>> Right. No need to hold all the developers hostage to a release model >>> we've been working to get away from >>. >> Please don't discount the risks such an escape entails: in particular, >> the "balkanization" of the source tree creates both technical risks >> (developers in one of the satellites may not pay enough heed to the >> needs of their dependents), and branding risks (the "known good" >> / quality management issue). > > This sounds like the job that Linux distributions are doing: taking > multiple packages that depend on each other in arbitrary ways, > integrating them and releasing the whole after it's been tested and > seen to work together. Good analogy: it points up the amount of effort required to keep the enterprise going. Note that there is a *lot* of brand equity in the distros that do this well, and that messing this up can cost users. Eggs should at least remove the majority of the burden of packaging individual software components, but only if the quality of the eggs stays high. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGlSwk+gerLs4ltQ4RAnmLAKCsBvW43SCKvA2/DQNr6sV7cw35bgCgiiLI ZCdxuBWbz8hoA0QWLVCWjHc= =cF7m -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope.app.session/zope.minmax
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Benji York wrote: > Tres Seaver wrote: > > [1] This means *never* doing 'svn mv' or 'svn remove' on such a tag, > > once announced. No exceptions, period, even for "brown bags". > > I can see that rule applying to eggs, but I'm not sure why we need > to do it for tags. I don't really object, but would like to understand > the motivation. Deleting tags of "bad" or ancient releases doesn't seem > particularly onerous. Removing a tag for a release is like removing and egg or a tarball: releases are *forever*. Satellite maintainers literally *cannot* know how / if a dependent is using that tag. For instance, if somebody has an external pointing to a tag, and you delete it, you break them. More insidious (and this is a bug in SVN, I think), if somebody uses a revision-qualified external to point at the tag, you *stll* break them, because SVN applies the revision qualifier *after* traversal. The "SVN bundles" promulgated in the Plone community are a fine example of this effect: there is no guarantee that a bundle you download and build today will be buildable tomorrow, because the "satellite" owners aren't careful enough about their release hygeine. If you make a "bad" release (I've done it myself), don't try to "cover up" like a cat on a linoleum floor: do the Right Thing(TM) and release *again*, with appropriate mea cupla / chest beating. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGlSQW+gerLs4ltQ4RAuMBAJ4lHSZ6tAb2wkGI0+e5DDJr5qXX3ACfd7w+ GQlq9tvoOIsAWEaDptdOj00= =itPQ -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: zope.app.session/zope.minmax
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fred Drake wrote: > On 7/11/07, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: >> Right, I made the same assumption: the eggs have been set free, > > Right. No need to hold all the developers hostage to a release model > we've been working to get away from. Please don't discount the risks such an escape entails: in particular, the "balkanization" of the source tree creates both technical risks (developers in one of the satellites may not pay enough heed to the needs of their dependents), and branding risks (the "known good" / quality management issue). We probably need to mitigate a couple of ways: - Document expectations for release management of satellite projects (e.g., immutability of "released" tags[1], keeping changelogs up to date, announcements to appropriate channels, etc.) - Implement the 'meta-eggs' *now*, and create buildbot scripts which automate testing of the built egg(s) and dependencies as an integrated whole. [1] This means *never* doing 'svn mv' or 'svn remove' on such a tag, once announced. No exceptions, period, even for "brown bags". Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGlR3a+gerLs4ltQ4RAjjYAJ9UFVNe23TJ51laZS0P5n7eBmyIQQCgkTuw lEyLK8kYlLvHqFY2+JBYa0Q= =jP4R -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Checkins] SVN: zope.schema/trunk/ More work on bug 98287: Introduced an event to signal that an object value is
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: > On Sunday 08 July 2007 13:19, Tres Seaver wrote: >> I don't see how that can be: 'zope.event' hsa no dependencies[1], and >> provides a service which is at least as low-level (lower, in my opinion) >> as 'zope.schema': I can imagine *lots* of Zope3-based applications >> which do not use zope.schema, but *none* which don't use zope.event, >> zope.interface, and zope.component. > > z3c.rml does not use zope.component and thus clearly not zope.event. I don't know why "clearly": 'zope.event' is a simple event channel notification model, which has no dependency on components at all. The application is free to do subscriptions in Python without any of the rest of the architecture at all. If anything, I would argue that schema's dependency on i18nmessageid is a wart, at least as a hard dependency. Using schema, but not component, has to be a one-percent case among Zope3 applications, I would think. You likely don't even want interface, in this case, since you aren't dispatching vies or adapters against your schemas. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGkY6q+gerLs4ltQ4RAumdAKDOdNbaWn82nIusA7xWm64FqHHQiQCgoJLy tyN33Wda0yRJ4E4l8ZZ1WbI= =eCOG -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Checkins] SVN: zope.schema/trunk/ More work on bug 98287: Introduced an event to signal that an object value is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stephan Richter wrote:
> On Sunday 08 July 2007 11:38, Christian Theune wrote:
>> Am Sonntag, den 08.07.2007, 11:31 -0400 schrieb Stephan Richter:
>>> On Sunday 08 July 2007 10:02, Christian Theune wrote:
>>>> Log message for revision 77624:
>>>> More work on bug 98287: Introduced an event to signal that an object
>>>> value is going to be assigned.
>>> Ahh, this is crazy! Why would zope.schema depend on zope.event, which
>>> depends on zope.component (if not by package, certainly by
>>> functionality)?
>> Because triggering an event seems to be a good way to separate concerns.
>
> This is true, but this is still just terrible. Setting the data within the
> field using setattr is just terrible. I know and understand the historic
> reasons, but Jim has argued for a long time abondoning this practice and I
> agree. Roger and I spent a lot of time developing z3c.form to overcome those
> original design flaws and to separate concerns, including data assignment and
> string to value conversion.
>
>> This field is setting the value and I find this pattern comparable to
>> what happens when you stick an object into a container which notifies
>> about an ObjectAddedEvent.
>
> For me zope.schema is a very low-level package, being below zope.event.
I don't see how that can be: 'zope.event' hsa no dependencies[1], and
provides a service which is at least as low-level (lower, in my opinion)
as 'zope.schema': I can imagine *lots* of Zope3-based applications
which do not use zope.schema, but *none* which don't use zope.event,
zope.interface, and zope.component.
> On one
> side we try to make dependencies more sane and on the other we add more
> dependencies. I care greatly about the dependencies of ``zope.schema``,
> because I use it for non-zope projects, such as z3c.rml. The more
> dependencies z3c.rml has, the more people will complain about it.
I would argue that theree
>>> Please revert. The solution is to rip out setting the value from within
>>> the field altogether.
>> Humm. Ripping out setting the value from within the field doesn't make
>> sense to me. The field is the only demonitator between zope.app.form and
>> zope.schema that I could find to make this happen reliably and IMHO
>> without hacking.
>
> Then hack, and let's deprecate zope.app.form.
[1] Per SVN for the eggs:
$ echo $ZSVN
svn+ssh://svn.zope.org/repos/main
$ svn cat $ZSVN/zope.event/trunk/setup.py | grep requires
install_requires=['setuptools'],
$ svn cat $ZSVN/zope.schema/trunk/setup.py | grep -C4 requires
package_dir = {'': 'src'},
namespace_packages=['zope',],
tests_require = ['zope.testing'],
install_requires=['setuptools',
'zope.i18nmessageid',
'zope.interface',
'zope.event',
],
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGkRy3+gerLs4ltQ4RAmByAKDbX2MRkQRAtVNi8qsiMPPYiFrFzgCfZiLj
SFlJbiD2461y3f++xwSdZ6Y=
=NwtU
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: Don't need $Id$ string any more
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tres Seaver wrote: > Stephan Richter wrote: >> On Wednesday 04 July 2007 08:08, Jim Fulton wrote: >>> I propose we stop bothering to include $Id$ strings. (Note that I'm >>> *not* suggesting we go out of our way to remove them.) >>> >>> Thoughts? >> I actually use that string all the time to determine who worked on the file >> last and when the work was done. I find it inconvenient to make another SVN >> call to get this information. > > 'svn stat' can give you that information without a network call; is > that too much trouble? Ooops, aorry, that should be 'svn info'. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGjRgd+gerLs4ltQ4RAkZVAJ4+7FviNwTV5m5ivhfw5IKFYSFU3wCfR8QB 7iui9YQDIjNhK7DpqSn85mE= =cTDx -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: Don't need $Id$ string any more
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: > On Wednesday 04 July 2007 08:08, Jim Fulton wrote: >> I propose we stop bothering to include $Id$ strings. (Note that I'm >> *not* suggesting we go out of our way to remove them.) >> >> Thoughts? > > I actually use that string all the time to determine who worked on the file > last and when the work was done. I find it inconvenient to make another SVN > call to get this information. 'svn stat' can give you that information without a network call; is that too much trouble? Tres. - -- ======= Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGjRKW+gerLs4ltQ4RAn/5AJ0YOY8qW2aDgDpgWkpJkF1V3XGpiwCfUCzB TUHpitaPRE9gzYgNzn/Gtss= =fa9s -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: Don't need $Id$ string any more
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fred Drake wrote: > On 7/4/07, Jim Fulton <[EMAIL PROTECTED]> wrote: >> I propose we stop bothering to include $Id$ strings. (Note that I'm >> *not* suggesting we go out of our way to remove them.) > > +1 +1. The only real win for those tags was in debugging problems in servers built against trunk / branch checkouts, a practice which we have happily shot in the head by now (www.zope.org is still there, unfortunately). > These have never proved anything more than distractions. Avoiding > them in the future is the way to go. Removing them opportunistically > (as modules get touched anyway) would be welcome gardening of the > codebase. - -1. Such cosmetic cleanup tends to make backporting patches harder, for very little win. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGjRI5+gerLs4ltQ4RApAIAJoDzEfURBaSbDZtze6t1nB044Z3fgCgoltP dVKghSyKt0fp55u0fivhh7U= =Ovre -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Trunk open for feature development towards Zope 3.5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: > On 5 Jul 2007, at 16:45 , Christian Theune wrote: >> Am Donnerstag, den 05.07.2007, 16:32 +0200 schrieb Philipp von >> Weitershausen: >>> Christian Theune wrote: >>>> I've made the release branch for Zope 3.4, you can feel free to >>>> start >>>> introducing changes for Zope 3.5 into the trunk of the tree. >>> It should be noted that the 'Zope3' tree actually contains little >>> or no >>> code at this point. >>> >>> I haven't yet see you make tags of the individual projects where >>> necessary. Will there be tags of those to represent their state in >>> the >>> Zope 3.4.0b1 release? What about when we go final? >> Right. I will make tags when we go final, I won't make tags until then >> because it's such a pain to keep them synchronised. > > Fair enough. > >> After the 3.4 final, >> we will (hopefully) never again point an external to a branch or the >> trunk but to tags and update the references as needed. > > Agreed. Note that a few packages already have 3.4.x with x>=0 tags. > Not that that's a problem, just so you know :). > >> I'm not sure what the interaction patterns are, e.g. who's responsible >> for updating the tree's pointers to newer packages. The maintainers of >> those packages? They probably know best ... > > I disagree. While Stephan raises a few good points that still need to > be adressed for the tree, I personally prefer not working with the > tree anymore. If people want to keep it around, that's fine, but then > they should maintain it. And their goals are likely different than the package maintainers: the "big tree" should prefer stability in its dependencies, and include new versions only when a particular feature / bugfix is deemed necessary. Note that I don't think we have figured out yet how to handle the "known good working set" problem: not having a handle on that is actually the biggest risk of eggification (really, of the "satellite project" model). Continuous integration (e.g., buildbot testing) against such a working set should be a major goal for us going forward. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGjRFx+gerLs4ltQ4RAlADAJ9lXZjabs0drB+8jtETVPpxmePZJQCgtbGq qbLYbDtW34Oyq6LYpDDnORg= =PJbd -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: using utilities/sites from threads in zope3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tim Stebbing wrote: > G'day, > > I've recently ran into a bit of a problem attempting to use threads in > zope 3.2.1, hooks.getSite() returns None, and any attempt to get a > utility results in a component lookup error within my threads. > > I've attempted to pass a site into a thread and set it with > hooks.setSite() but this is apparently not the way to go, I get the > feeling that a thread that needs access to things form the database > probably needs its own connection, context etc. Your worker thread almost certainly needs its own database connection(s): applicaiton code typically relies on the isolation provided by connection-per-thread, which means that it is not "safe" in general to share persistent objects between threads. Assuming that you do grab a connection and get its root object, you should then be able to traverse to your friendly local site manager, calling 'setSite' at *each* parent site manager you pass along the way. > I'm aware of ITask's but unsure if developers are supposed to use them > for their own purposes? Do these handle setting up of contexts like > db, site, global utils etc? I've googled around a fair bit and been > over all the z3 doco, it would be great if there was a simple howto on > setting up a thread that would have the usual access to various > components. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGhQEG+gerLs4ltQ4RAh6EAJ9DzBW20NPz4tAE3BydJ789Vokx0wCg2qMp yBB8XemrjD7dXPwwwz4y9Yo= =+iwh -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Checkins] SVN: zope.app.form/trunk/src/zope/app/form/browser/te FileWidget tries to be smarter about not deleting the currently stored content when the user did not upload a new fil
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Zagrodnick wrote: > On 2007-06-27 16:13:06 +0200, Gary Poster <[EMAIL PROTECTED]> said: > >>> newvalue is not formfield? To me this does not make much sense. Why >>> would I return self.context to indicate the value has not changed? >> As the comment says, looks like form_field is being used as a >> marker--.get should (hopefully) never return form_field, which is >> precisely the point: that way, if get returns form_field, that means >> that there is not a new value of any sort. > > Geeh. I'm so blind. :( That is actually why I am against the practice of using "real" objects as markers, instead of artificial ones with obvious names: it makes the reader stop, and breaks the flow. Too clever by half, as it were. Trse. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGgqbq+gerLs4ltQ4RAj+BAJ9dmoFi6x6wJqa/2oYxpkv+0m6AYwCeO3g2 5dZZpJIeW3ayN3yH96qnotA= =eLd6 -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: zc.zope3recipes not working on Windows
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: > On May 31, 2007, at 1:59 AM, Stephan Richter wrote: > >> Hi Jim and other zc.zope3recipes experts, >> >> I have had some reports from Windows users that the z3c.formdemo -- >> which is >> built with zc.zope3recipes -- is not working on Windows. The >> reported error >> was as follows: > > The instance recipe should advertise that it only works on Windows, > because it is based on zdaemon. I tend to forget that zdaemon > doesn't work on Windows. :/ > > This isn't easy for *me* to fix because I don't have enough Windows > foo. I'd be happy to work with someone who knew Windows well, > especially services (or other long-running process options, if > any). If anyone like that is going to be at the sprint at the > upcoming DZUG meeting, I'd be very happy to work with them there. > > A partial fix that only supports the ctl 'fg', 'run', and 'debug', > commands should be fairly easy, although I'm a bit hesitant without > understanding how we might want this to work in the long run. Hanno has checked in a Zope2 patch which makes 'zopectl' work on Windows, and adds two new Windows-specific commands to install and remove the Zope servvice: http://svn.zope.org/Zope/trunk/lib/python/Zope2/Startup/zopectl.py?rev=75066&view=rev Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGYBIS+gerLs4ltQ4RApPhAKCSDHbKZaZscV0kAImFF0fOjyGZ4QCcDkvP ADEI5FEu1BRMvFtMXw0hbbg= =k/fy -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: A thought on backward compatibility and minimum versions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: > On May 31, 2007, at 10:58 AM, Tres Seaver wrote: >> I'd rather have the dot, e.g. "foo 2.* >= 2.5", just for clarity: >> >> - It makes the intent clearer (that you want any version in the >> "two dot" release line). >> >> - It disambiguates the case where the version number might have >> double digits (e.g, '0.1' vs. '0.10'). > > This depends on how the * is interpreted. setuptools already treats > dots as optional in many cases and this would be one more. I also > prefer the last syntax I suggested without the "*". So, the example > would become: > >"foo 2, >=2.5" That seems like an empty set to me. > (I forgot commas in my earlier examples.) > > Without the *, I think there is less of tendency to interpret the > specification as a glob. > > >> Another feature I'm not sure is already in setuptools: >> >> - I *don't* want dev releases to replace production ones >> implicitly: no package should be able to install a non-released >> version without explicit callout. If this isn't already the >> default behavior, then I'd like syntax for spelling it. > > What do you mean by a "dev" release? Any release tagged as "alpha", "beta", "rc", "pre", or with an SVN revision. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGXuZs+gerLs4ltQ4RAgrgAKCkXrIkwHzegujOnobtd9T3TzwO0ACfWXNY NZLXDYZDyk7ADYy/2kKllUE= =W5nx -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: A thought on backward compatibility and minimum versions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: > In thinking about how we might specify that we want to depend on > major versions but sometimes need to specify minimum versions, the > following occurred to me: > > - Suppose that we always had access to the latest released version, > > - Suppose that, within a major release, all releases were backward > compatible, > > Then I assert that there is no *need* to specify a minimum release > within a major release. > > Consider an example: > > I depend on foo 2 (foo >=2 <2.999). Now foo 2.5 introduces a new > feature and I use this feature. In reality, I now depend on version > 2.5 or higher (and <2.999). I shouldn't need to specify this. After > all, I'll always get new releases. Why wouldn't I? Well, I might > also depend on bar and bar might depend on foo <=2.4. Why would bar > do this? The only sane reason is that 2.5 introduced a backward- > incompatible change, but we don't allow that. If we don't have to > worry about backward incompatible changes within a major release > cycle, then there is no reason to set an upper limit and therefore, > there is no *practical* need to specify a lower limit. > > Combined with the fact that that great majority of packages don't > change very much after they have become stable, I think most package > dependencies could be expressed very simply if there was a simple > syntax to specify *just* the major version. In the context of > setuptools, I think "*" could be used, as has been suggested, but > without leading =s. So, to specify foo version 2, I think the > following syntax would be very reasonable: > >foo 2* > > This wouldn't prevent someone from specifying a minimum version. For > example, to combine this with a minimum requirement of 2.5: > >foo 2* >=2.5 > > If people like these ideas, I'd be willing to lobby for them on the > distutils sig, especially if I have help. :) > > Note that the proposal would be that, a specification of the form if > a version number followed by a * would be equivalent to a range: > > "project_name V*" is equivalent project_name "V.*" is equivalent > to "project_name >=V > (Or maybe equivalent to "project_name >=V.dev <=V.9".) > > Also note that It's not clear that the * is needed. > > "foo 2" isn't a valid specification. We *could* extend the > requirements language to allow a project name followed by a version > number. So: > > "prject_name V" is equivalent to "project_name >=V = 2.5", just for clarity: - It makes the intent clearer (that you want any version in the "two dot" release line). - It disambiguates the case where the version number might have double digits (e.g, '0.1' vs. '0.10'). Another feature I'm not sure is already in setuptools: - I *don't* want dev releases to replace production ones implicitly: no package should be able to install a non-released version without explicit callout. If this isn't already the default behavior, then I'd like syntax for spelling it. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGXuKo+gerLs4ltQ4RArrWAJwMowPxfb95Jl7oAUCZUQCRD7o8kQCcD9+G kGpfoL51tpgWWWlgpOwXktY= =5KVO -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Splitting package configuration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fred Drake wrote: > On 5/23/07, Stephan Richter <[EMAIL PROTECTED]> wrote: >> Thinking about it more, it would actually be backward-compatible, since we >> never released the packages in themselves but always as part of the Zope 3 >> bundle. Also, even the packages that are not hooked in via zope.app.zcmlfiles >> are added via the automated SETUP.cfg stuff. At least this is the official >> story right now. :-) > > "Official story" doesn't mean a lot to me these days. I think of > individual ZCML files as interface points: someone might reasonably be > using them directly (unless the filename starts with an underscore). > >> I hope it is avoidable with the above insight. > > Again, if you think there's an official story that involves > *requiring* people to rely on those nasty slug files, you're deluding > yourself. We've always maintained that those are "convenience" (for > some definition of "wouldn't you like to shoot yourself in the > foot?"). Hmm, the use case for slugs was to support "application with separately installed extensions"; Fred, I think your view is prejudiced by the fact that you don't have any need for pluggability / extensibility. Stephan is arguing for finer-grained configurations, which is likely to be better for reuse, at the cost of *reduced* convenience. >> Really? That would be a pitty, because it would allow us to have one release >> with the old and the new way, so the first people can migrate. > > Would be a pity, yes, but it'll never happen if we keep changing it. I don't know what is blocking a 3.4 release. AFAIK, eggification is on the roadmap for 3.5, right? So we should be focused on stabilizing the "last zpkg build", while still allowing the eggified / broken-out project model to move forward. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGVG09+gerLs4ltQ4RAjecAJ4hIciB875Jm8u1h1C24LTgNVTqXACgljZS mkG3T52u6XohWzm0V9kUCIM= =aekr -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: System python for *development*? (Was: 3.3.0 tag broken by zc.catalog eggs?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marius Gedminas wrote: > On Mon, May 21, 2007 at 12:21:42PM -0400, Tres Seaver wrote: >> Reinoud van Leeuwen wrote: >>> On Mon, May 21, 2007 at 10:39:22AM -0400, Fred Drake wrote: >>> As a developer it might be a good idea to have different installed pythons >>> in different environments to be sure that some modules (or python itself) >>> meet different requirements. >>> >>> But as system maintainer I like to keep things simple. I do not want >>> similar trees of python installations all over the place if it can >>> be avoided. >> Just as with Java-based applications: if the server's job includes >> running Zope, then installing a separate Python interpreter is a pretty >> low cost, with the following benefits: >> >> - You don't risk breaking your production Zope application in a >>distro-mandated upgrade to Python (e.g., Fedora 7 puts Python 2.5 >>into /usr/bin/python). > > That's probably the best reason. I ran away from Debian's Zope 2.x > packages because they made upgrades painful. > >> - You may not want to pay the cost of a Python optimized for desktop >>applications (UCS-4, anyone?) > > Do you have any numbers? How much memory of a typical Zope 3 app is > taken by Unicode strings? (I'm not trying to invalidate your argument, > I'm genuinely curious.) No hard numbers, except a vague recollection of shock at the difference in two appservers running the same application, where one was running using a UCS-4 interpreter. Given that pretty much *all* ZPT rendering these days involves Unicode manipulation, lots of the "transient" memory used while rendering a page (as opposed to the ZODB cache) is potentially affected. >> - You may need to patch Python to work around a bug which is only >>problemnatic for long-running Python instances (e.g., the >>longstanding cgi.FieldStorage DoS problem). > > I don't think that's a good example. I'd rather patch Zope in this > particular case. De gustibus, I guess. Patching Python to work around issues which affect your own application, but where the patch may languish in the SF tracker for more than a year seems reasonable to me. #112549 comes to mind, for instance: although reported against Python 2.3 while 2.3 was still in maintenance, the fix never did make it into a 2.3 release, and missed three third-dot revisions on the 2.4 side. >> - You can create a repeatable environment for testing each deployed >>application, even where those applications are running on boxes >>with different OS / distro-supplied Pythons. > > There's still a point where you stop, right? You don't have a > self-compiled libc and a self-compiled C compiler to make sure your > self-compiled Pythons are really identical? I don't go that far (yet ;), but I often do end up building other non-Zope components: - libxml2/lxml, for instance, because the OS-provided one has typically been too old, and because getting the Python wrappers built any other way is a nightmare - postgres, because I want to use Python as a stored procedure language. - Squid3 for ESI. - (hypothetically) Apache + mod_python, because it hard-wires the location of the Python iterpreter / DLLs. The end result is that we can develop on laptops (Linux or Mac) and deploy to production boxes (various Linux flavors, FreeBSD) with a fair amount of confidence that the pieces all work as expected; the platform-specific bits all get manaaged as part of the buildout libraries. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGUuOw+gerLs4ltQ4RAiHTAJwL8XV3wdDdzcyKP6/PDbboerU8oQCeLdIj w3R+bkVczZtCvOZXl19/Qjc= =hqDF -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: System python for *development*? (Was: 3.3.0 tag broken by zc.catalog eggs?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: > On May 21, 2007, at 1:39 AM, Martijn Pieters wrote: > >> On 5/21/07, Gary Poster <[EMAIL PROTECTED]> wrote: >>> FWIW, I know zc.catalog but I'm certainly not an egg expert. But >>> this message looks like you are maybe sharing a Python for various >>> installations. Are you maybe using your system Python? Generally >>> not advised for development work...try a standalone one? >> Come again? Using the system python when developing has always been >> fine; > > No. It has never been fine for any aspect of development. If you > develop with your system Python and deploy with a custom environment, > then you've added a variable that is different between the two > environments. Also, system Python's are often hobbled in ways that > hurt development. > > I sometimes get really weird error reports that are traced to system > Pythons. People who report problems to me that result from using a > system Python make me angry and make me want to not answer their > questions or otherwise help them any more. > > System Python's have their place. The are appropriate for casual > Python users and small one-off scripts, but not much else IMO. > >> the recommendation has only applied to deployment situations in >> the past. The point is that using a manual, dedicated build for a >> deployment gives you full control over tweaking that build for best >> performance without interfering with other users of the interpreter on >> the same system. >> >> I run dozens of development instances on my laptop, all with the same >> Macports python 2.4 installation. Creating a separate python build for >> each of these would be impractical, to say the least. > > You don't have to use a Python per project to avoid the system > Python. Just create a separate from-source installation and use that > single installation. *Never* install anything into that > installation. Whether you are using eggs or not, any packages not > included in a Python build from source should be managed in your > project area. Of course, eggs make this easier. > > (IMO, it is also reasonable to include a Python build in a buildout, > as long as it automated and as long as you don't mind the extra disk > space usage and build time. I prefer to use a shared clean Python > myself.) > >> However, it appears that the switch to eggs requires additional >> precautions to avoid your python system to be 'polluted' with various >> Zope3 packages. Perhaps we should recommend using workingenv for >> development work instead? > > Yes, as others have mentioned, you should use workingenv or > buildout. (I wrote buildout because workingenv didn't provide enough > control or automation for my needs.) I use virtual python for this, actually: the separate tree makes it possible to allow distutils / easy_install to "pollute" their own, private site-packages directory without my having to fight with sys.path. The cost there is a separate copy of the Python interpreter per runtime environment, plus a mess of symlinks. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGUcfU+gerLs4ltQ4RAshBAKCdX1/0rZ4Fwj3aEfdlHVulDgZ5jQCgxbd0 VYBGtQsCnOvji6o5MJxEIRI= =UUJv -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: System python for *development*? (Was: 3.3.0 tag broken by zc.catalog eggs?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Reinoud van Leeuwen wrote: > On Mon, May 21, 2007 at 10:39:22AM -0400, Fred Drake wrote: >> On 5/21/07, Gary Poster <[EMAIL PROTECTED]> wrote: >>> I then >>> feel comfortable sharing the dev Python across builds because I know >>> it is clean. >> The stuff that gets installed in the system Python's is usually not an >> issue for Zope applications (I've never had a Zope-related issue with >> those things), but I always use a clean Python just to be safe in case >> something odd gets added to the system Python. Ubuntu and the various >> RedHat-derived systems (Fedora, CentOS) add enough to the system >> Python that I'd rather avoid them for applications regardless. > > I think developers and system- or application maintainers have different > viewpoints in this. > > As a developer it might be a good idea to have different installed pythons > in different environments to be sure that some modules (or python itself) > meet different requirements. > > But as system maintainer I like to keep things simple. I do not want > similar trees of python installations all over the place if it can > be avoided. Just as with Java-based applications: if the server's job includes running Zope, then installing a separate Python interpreter is a pretty low cost, with the following benefits: - You don't risk breaking your production Zope application in a distro-mandated upgrade to Python (e.g., Fedora 7 puts Python 2.5 into /usr/bin/python). - You may not want to pay the cost of a Python optimized for desktop applications (UCS-4, anyone?) - You may need to patch Python to work around a bug which is only problemnatic for long-running Python instances (e.g., the longstanding cgi.FieldStorage DoS problem). - You can create a repeatable environment for testing each deployed application, even where those applications are running on boxes with different OS / distro-supplied Pythons. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGUccW+gerLs4ltQ4RAkkfAKCOaC+YC65MWa2NCzuSGTZtCB4D6QCbB9Sd Vfr82aBHbxU+EWmPS4x2/hs= =P6jl -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: what dependency to use for "zope 3"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bernd Dorn wrote: > On 11.05.2007, at 17:29, Chris Withers wrote: > >> Fred Drake wrote: >>> On 5/11/07, Chris Withers <[EMAIL PROTECTED]> wrote: >>>> I dunno, do we actually need an "offical big zope 3 release" >>>> anymore? >>> No. What's more, we don't even want to use one anymore. >> cool :-) >> >> My only slight concern here is when people make changes in one >> satellite project, they break another one and don't realise. But I >> guess the buildbot should catch that, right? > > i talked with jim about this and we agreed in that specifying > versions in eggs is not a good idea. The best way imho is to use > buildout's 'version' section in your application's buildout to nail > down all eggs to a specific version. - -1; a "meta" egg would work fine as a place to specify hard-wired dependencies. Not every Zope3 user is going to be using buildout. Note that such a "mega-egg" would likely specify the "transitive closure" of its dependency graph, as well. Whether such a mega-egg is called an "official Zope release" is a different issue, but that would be one way to let folks download a "known good" integration (a distribution?) of the various satellite projects. +1 for avoiding gratuitous version-specific dependencies in "library" eggs; unless there is a known incompatibility, eggs should specify their dependencies by name. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGRKMK+gerLs4ltQ4RAgxeAKCbX3U0hNE2l1JPH22KYDnK/JcxtQCdGbOR sMt6iOipMshWC4VWJ/2UuMI= =bltZ -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Contact info, Bethany Nohlgren
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bethany Nohlgren Assistant Dean of Students and Director of First-Year Students x7454 [EMAIL PROTECTED] Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGQ4b1+gerLs4ltQ4RAvGhAKDE0zml1tx/gJOG6cUHYlMCLI627gCgpC3a vxCmG354sZrJIu8/xEmU2Is= =gZrd -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Branches for individual projects ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Baiju M wrote: > Hi, > Shoul we cut branches for individual projects (in zope and > zope.app namespace) for bug fixing when 3.4b1 releases ? - -1 to creating them en masse; branching the sub-projects should be at the discretion of their maintainers, and should not be driven by policy at the Zope level. Again, if we aren't going to do separate release management on the subprojects (which I'm in favor of, mind you), then we shouldn't be splitting them out from the main Zope tree. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGQ4HI+gerLs4ltQ4RAi5pAJ4m9w53J1uG0GaokMQzcJGhvYrUoACgoblE 5o0LwxiYmi/3NJFuGNkZHOw= =zJsa -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: tracking satellite project's trunks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Theune wrote: > Hi, > > Am Donnerstag, den 03.05.2007, 13:18 -0400 schrieb Tres Seaver: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Fred Drake wrote: >>> On 5/3/07, Christian Theune <[EMAIL PROTECTED]> wrote: >>>> I started moving packages to their own projects (manually right now, >>>> preparing for doing this scripted) and noticed that zope.index is >>>> tracked with a specific revision number. >>>> >>>> My understanding is that the trunk of the Zope 3 tree should be tracking >>>> the trunk of the satellite project's tree without pinning it to a >>>> revision. >>> Probably my fault; I've become really wary of externals that aren't >>> specific. >>> >>> Frankly, I don't *really* care how the Zope 3 tree refers to satellite >>> projects. My hope is that I can very quickly get away from ever >>> looking at the Zope 3 conglomeration (checkout or release), and only >>> use the satellite projects. >>> >>> Conversely, I care very much about the satellite projects not >>> referring to the Zope 3 tree, and look forward to what you're working >>> on today. >> When a truly egg-based Zope3 ships, it should be a meta-egg with >> explicitly-versioned dependencies. >> >> Approximating that in tree would be to have the Zope3 tree point at >> *tagged releases* of the satellite projects; revision-stamped versions >> are a poor (but acceptable in the near-term) substitute. > > Same here. I'm feeling like I'm not yet understanding what the trunk > will be used like. > >> Tracking the trunk of any dependency is not acceptable: >> it undoes the reason for >> moving the projects out-of-tree in the first place. If we aren't going >> to do release management on the pieces, then for sanity's sake keep them >> in-tree. >> >> Plone's own trunk-based bundles are living proof of the hell that is >> caused by having svn:externals point at non-frozen dependencies. > > Ah. I don't have any experience with those. What would the trunk of the > Zope 3 tree look like then during development cycles? When do updates on > the externals in the Zope 3 trunk happen? Typically whenever somebody who knows both "decides" that the satellite has changes which need pulling into Z3; at the latest, they get updated when doing a Z3 release, I would guess. This is like what happens now with ZODB, etc., or with Zope3 as an external in Zope2. I think we are headed to a place where much less "trunk-like" development, except for things which have not yet (or maybe ever) been spun off into satellite projects. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGOmDp+gerLs4ltQ4RAtYzAJ9E7W9Ate0Ntr1rSxP28wcuk+gROACgrR+g 2HDuD9SkZkEWYpPvU5sRqmI= =UCYx -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: tracking satellite project's trunks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fred Drake wrote: > On 5/3/07, Christian Theune <[EMAIL PROTECTED]> wrote: >> I started moving packages to their own projects (manually right now, >> preparing for doing this scripted) and noticed that zope.index is >> tracked with a specific revision number. >> >> My understanding is that the trunk of the Zope 3 tree should be tracking >> the trunk of the satellite project's tree without pinning it to a >> revision. > > Probably my fault; I've become really wary of externals that aren't specific. > > Frankly, I don't *really* care how the Zope 3 tree refers to satellite > projects. My hope is that I can very quickly get away from ever > looking at the Zope 3 conglomeration (checkout or release), and only > use the satellite projects. > > Conversely, I care very much about the satellite projects not > referring to the Zope 3 tree, and look forward to what you're working > on today. When a truly egg-based Zope3 ships, it should be a meta-egg with explicitly-versioned dependencies. Approximating that in tree would be to have the Zope3 tree point at *tagged releases* of the satellite projects; revision-stamped versions are a poor (but acceptable in the near-term) substitute. Tracking the trunk of any dependency is not acceptable: it undoes the reason for moving the projects out-of-tree in the first place. If we aren't going to do release management on the pieces, then for sanity's sake keep them in-tree. Plone's own trunk-based bundles are living proof of the hell that is caused by having svn:externals point at non-frozen dependencies. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGOhlO+gerLs4ltQ4RAk80AJ9NxzHr0QQScDMOPZ9uc9MOobA4owCfV58Q TwFv3cpDbgYlfTPaB1a5RMs= =uL9A -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: yagni on overrides?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: > Tres Seaver wrote: > [snip] >> One example of such an implementation would be an optional, lxml-based >> directive which uses the native structure of the ZCML file and XPath. >> E.g. to include only adapters from a package :: >> >> >>//adapter//path> >> >> >> The XPath processor would need to be passed the current namespace >> mapping here, if we want to select items from the non-default namespace. >> Otherwise, this would function pretty much like the 'include' directive >> (it might even use that diretive's handler under the hood). >> >> With an egg-based story, we can more easily use stuff which depends on a >> third-party library like lxml; folks who can't install lxml just lose >> this feature. > > In general, I don't like relying on the syntactic structure of ZCML > files for this. I'd prefer to have a semantic of configuration actions > and a way to disable them. > > If this can be a quick fix that helps people, so be it, but I think a > way to manipulate configuration actions from Python code is a better > overall approach. I disagree, as I've said before: I don't want policy in software. This may be de gustibus at this point. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGMiVz+gerLs4ltQ4RAnzKAKCmTFyb+a05W2+4DolvtZEJXIP3uACgyXZ+ wsQBv4pQEGXjfDwnGqtjnJI= =ueYm -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: yagni on overrides?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: > I'll note, mostly in passing (drive by :) that overriding utilities, > adapters, security setting and many other things, works pretty well > and has for a long time. What doesn't work well is disabling things > or dealing with things, like subscribers that can't be overridden, > because they never conflict. In practice, this usually doesn't matter > because, elegance aside, there usually is no harm in having extra > configuration. Of course, there are times when it does matter, and I > think we need something to help in those cases. > > I do think that Leonardo makes a valid point that factoring > configurations might work just as well. If we had a way to disable > configuration, say with a tagging system, then people would have to > anticipate selective reuse by providing appropriate tags. At this > point, you might as well just factor the files. Some of the > proposals for configuration disabling didn't require explicit tagging > but could use existing properties of configuration. One example of such an implementation would be an optional, lxml-based directive which uses the native structure of the ZCML file and XPath. E.g. to include only adapters from a package :: //adapter//path> The XPath processor would need to be passed the current namespace mapping here, if we want to select items from the non-default namespace. Otherwise, this would function pretty much like the 'include' directive (it might even use that diretive's handler under the hood). With an egg-based story, we can more easily use stuff which depends on a third-party library like lxml; folks who can't install lxml just lose this feature. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGMfRd+gerLs4ltQ4RAt0oAJ9P7uzGpg+9aUxojOncmwNqap57ewCdHxmw 8c8sBw06QuruSXLdAjbXBBg= =4/9I -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Autoconfiguring a site.zcml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: > Hello, > > Tres Seaver wrote: >> David Pratt wrote: >>> On the basis that eggs spell out dependencies, I am thinking the >>> inclusion of packages and their dependencies should be enough to dictate >>> the sequence of inclusion for package configuration (and creation of the >>> site.zcml) for the app buidout recipe. This could be a option to the >>> current manual configuration. >> - -1. Configuration is *policy*; implicitly wiring in the default >> configuration for every egg on the path is not going to be an acceptable >> default. > > In the path? David didn't say in the path, did we? What about in the > buildout? Since my buildout already says explicitly it wants egg foo, > and egg foo needs egg bar, it is a major pain to have to specify the > ZCML for bar manually. > > I don't think something being policy means it's automatically a bad > candidate for automation. Information about the policy may after all be > elsewhere in the system, for instance in a buildout.cfg. You don't see cases already where you want to use something from somebody else's package / egg, but don't want to accept every configuration choice they make? This is pretty hard to do if the system automagically wires in every pacakge's 'configure.zcml'. One of the big knocks against Zope2's 'product" story was exactly this: there was no way to use a product without accepting its entire "configuration." >>> Presumably, the reason folks would use this recipe is to configure one >>> or more of the same app. I know attempting to do this manually is prone >>> to errors if packages are not in the correct sequence or if you miss the >>> configuration of a package. Any thoughts on this. Many thanks. >> Not necessarily. There are really two kinds of packages in play here: >> "libraryish" packages, which supply mechanisms, and "applicationish" >> packages, which use the mechanism according to some policy. I would >> argue that the only things you can safely auto-include would be the >> 'meta.zcml', because it is policy-free. Reusable packages need to avoid >> imposing policy (they may *suggest* it, but they shouldn't insist). > > That's where we have the concept of overridable defaults. So the default > should be to follow the suggestions, and there should be an option in > the system to override this suggestion. There is not such place right now. The 'includeOverrides' directive is not expressive enough. >> I would cheer if somebody proposed writing a UI which introspcts >> packgaes for such suggestions, and allows the site manager to merge / >> override them to create an appropriate 'site.zcml'. Until then, I don't >> want package authors dictating to site managers. > > Who are these ZCML-using site managers you are speaking of? Anyway, are > you saying you want some form of ZCML UI to be created before *any* > automation can be implemented? Asking for the creation of a UI on the > Zope 3 mailing list is paramount to waiting forever... *I* am the user I'm talking about: I want to be able to use others' components without swallowing whole their configuration choices; today, that means copying and modifying their 'configure.zcml' files. > If you never automate policy, you'll be writing a lot of stuff by hand. > That may be fine for you, but I myself would prefer to write less boring > code and focus on more interesting problems. Automation which is hard to understand and override is the source of the "Z shaped learning" curve which plagued Zope2; it also plagues other convenience-oriented frameworks outside of Zopeland. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGK4lm+gerLs4ltQ4RApoUAJ4g8t3xOSqAsIAcIawKy0xwgYrBqACeKoxJ 2Bq3bKeJZkT+sf/bxx5UUMQ= =TbFf -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Autoconfiguring a site.zcml
our app configuration. In experimenting, the bottom line >> is it doesn't really matter where it is - because is really the >> same size regardless of where the pieces reside. So I have been >> considering - what am I really trying to do here - and how much >> grief do I want to encumber putting it all together. The semantics >> of having a large site.zcml that takes care of app configuration is >> not inconsistent with the fact that I am using the buildout to >> configure and build my app. So in the end I would be happy to >> consider a larger site.zcml that does the work of organizing >> includes to all packages in the app. And at the package level being >> left with just making the includes within it (such as including a >> browser or an ftest sub package) to complete the configuration tree. > > Are you saying that If A depends on B and B depends on C that you > expect A to only have to include B's ZCML and rely on B's ZCML to > include C's ZCML? I think that's a reasonable strategy. > > (It would be more reasonable if we filed some holes in ZCML > overriding, but that's a different topic.) > > >> That said, I don't relish to time it will take to looking at >> ordering all of the includes in a site.zcml. > > You shouldn't have to. > > ... > >> Overall, it should not matter really as far as I can see. If egg1 >> needs the contents of egg2, it stands to reason that that package >> includes of egg2 need to be pushed higher in the site.zcml that >> those of egg1. Further if we adhere to good information in the egg >> we should not have to worry that imports of packages in eggs will >> not work. So I tend to believe that some means of scoring, >> weighting or boosting could be used together with the exploration >> of each egg for a configuration (*-configure.zcml, *-meta.zcml) to >> autogenerate the site.zcml as the buildout proceeds. > > I don't think this is necessary. An egg that has ZCML should load > the ZCML from other eggs it depends on. This means that these eggs > have to be designed this way. Our override story is too weak to support this now, because the author of package "C" may make a configuration choice which is inappropriate for how "C" is used in "B" or "A": we have no way to "turn off" such choices (we can shadow them, but not disable them). We really need a way to spell "include the configuration from package 'A' except for the view registrations" or "include only the utilitiy registration for the 'IFoo' utiltiy from package 'B'", or else we need to make the configurations much more fine-grained. Otherwise, we end up in a situation where using a package means accepting all of its configuration blindly; at that point, there is no win to moving the registrations out of Python code in the first place. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGK4aD+gerLs4ltQ4RAlynAJ9Vk6tvBwy2Yo7+j75lAThn/3tr7gCfVT58 KanroIFTmluTstFlsNCllD8= =YXiT -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Autoconfiguring a site.zcml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Pratt wrote: > On the basis that eggs spell out dependencies, I am thinking the > inclusion of packages and their dependencies should be enough to dictate > the sequence of inclusion for package configuration (and creation of the > site.zcml) for the app buidout recipe. This could be a option to the > current manual configuration. - -1. Configuration is *policy*; implicitly wiring in the default configuration for every egg on the path is not going to be an acceptable default. > Presumably, the reason folks would use this recipe is to configure one > or more of the same app. I know attempting to do this manually is prone > to errors if packages are not in the correct sequence or if you miss the > configuration of a package. Any thoughts on this. Many thanks. Not necessarily. There are really two kinds of packages in play here: "libraryish" packages, which supply mechanisms, and "applicationish" packages, which use the mechanism according to some policy. I would argue that the only things you can safely auto-include would be the 'meta.zcml', because it is policy-free. Reusable packages need to avoid imposing policy (they may *suggest* it, but they shouldn't insist). I would cheer if somebody proposed writing a UI which introspcts packgaes for such suggestions, and allows the site manager to merge / override them to create an appropriate 'site.zcml'. Until then, I don't want package authors dictating to site managers. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGKk8D+gerLs4ltQ4RAs+UAJwLA3ek+JiOq0uRsngZlNCE7IwG8ACg3B5k Y+XVfMoyN+cJhLE70j2b638= =aLQy -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Grok sprint 2 reports
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tres Seaver wrote:
> Rocky Burt wrote:
>> On Wed, 2007-10-01 at 11:09 -0500, Tres Seaver wrote:
>>> While I am vehemently opposed to code generation per se, one alternative
>>> which I think is important is to generate stuff *at runtime* from
>>> artifacts which are more understandable to business users than Python
>>> code. E.g., they might specify schema in a spreadsheet, an HTML form,
>>> or a UML diagram, which we then use to create a schema interface (my
>>> 'userschema' package[1] does this already for the first two).
>> Not sure which mailing list my questions belong on but for the time
>> being I'll ask them here (any list subscribers feel free to tell me to
>> take this discussion offline).
>
>> This userschema package looks very cool and it's nice to see all the
>> cool ways you can produce schema's from user contributed data (ie csv,
>> html). But I'm curious to know what sort of use cases you have for the
>> end-result schema's ... simple formlib form generation? content type +
>> edit form (via formlib) generation?
>
> Obviously generated UI is the main use-case; I have some notions about
> making it easier to use schema stuff from within "custom" UI, but they
> aren't fleshed out yet.
>
> I do have a notion of allowing the template which *specifies* the schema
> to be used to *render* its fields, but haven't got that part working
> yet. Chris McDonough and I have talked about using a meld3-based
> approach to that, as well.
(Sorry to follow up to myself, and so late).
While at the BBQ sprint last month, Philipp and I worked on a prototype
for this last idea. Although it isn't cleaned up yet for a release, the
essence of it is to put the 'index' and 'edit' templates (hand-rolled,
of course) into the appropriate subdirectory, and then use a new grok
directive to get the class and all its views wired up. E.g.::
$ cat simple_templates/index.pt
BODY
$ cat simple_templates/edit.pt
Simple Body
$ cat app.py
import grok
import grok_crud
from zope.formlib import form
class SimpleApp(grok.Application, grok.Container):
pass
class Index(grok.View):
grok.context(SimpleApp)
class Simple(grok_crud.Crud):
grok_crud.directory('simple')
With something like meld3, we could even get rid of the hairy TALES
expressions in the tmeplates, making them purely the domain of the designer.
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGKNxM+gerLs4ltQ4RAu0AAJ9/l7K9l5TkMLCOAp/rdExACfpItACgxRpq
X4p0vh6t5WKEJPmihBjf3qo=
=CHwU
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Grok sprint 2 reports
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Max M wrote:
> Martin Aspeli skrev:
>> Peter Bengtsson wrote:
>
>>> Will the grok effort yield any codegenerating scripts and stuff like
>>> the django folks have?
>>> If not, I have some ideas that I could maybe contribute with at/for
>>> the next sprint even :)
>> Code generation sucks. :)
>
> (I know it is late to participate in this thread, but I am reading up on
> grok.)
>
> I used to have the above opinion too. But I have changed my mind.
>
>
> A good framework will get you up and running with as little resistance
> as possible.
>
> But actual real-life projects will often need a lot of files,
> configuration and settings.
>
> So you might start out mean and lean, but after you are done fixing all
> the little special cases and customizations, you will still have a lot
> of code.
>
> If all that code you end up with anyway is automatically generated, it
> will have an educational effect on the community. A "Code by Numbers"
> effect where you fill in code in the obvious slots.
That presumes that the framework is omniscient / presient enough to
leave slots in place to allow the customizaitons you want. I *hate*
fighing some UID-generateing architecture ("wiggling the wires") to get
the customer's desired UI.
> Just see how easy it is to check out other peoples AT based code in
> Plone. Simply because everyone are acustomed to the structures and
> conventions.
I think you just proved Martin's point: in my experience, maintaining
other people's AT-based code is like Napoleon before Moscow: thigh deep
in freezing mud.
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGKM+2+gerLs4ltQ4RAlqyAJ9/5MlxmBy+nAYJUkmrrtCPt0aHMwCeOr3X
T0RmJNDsVnTMl4iARwFtL2E=
=Q4CN
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope3 Standalone Page Templates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeff Peterson wrote: > I am trying to get Zope3 page templates installed as a standalone > package. I thought this would be easy and maybe I am missing something, > but, I am having no luck at all. > > I have seen several posts regarding doing this, but none of them seem to > work any longer. On used zpkg to get the package and build a tarball, > but the packaging failed with the data that was given, as files in the > svn repository were moved. I looked around the for another method of > getting them from svn but could not come up with anything. It looks > like the files might be there to retrieve but I am unsure how. > > I tried to use the pagetemplate folder from a zope3 install but I cannot > seem to get python to see it properly. The app that is looking for them > imports them as such: > > from zope.pagetemplate import pagetemplatefile > > My goal was to install this in the site-packages folder in my python > install. If anyone has any input at all it would be appreciated. > > TIA, Have a look at the source distributions / eggs available at: http://download.zope.org/distribution/ Also, a checkout of the following might be instructive: svn+ssh://svn.zope.org/zope.pagetemplate/trunk For instance, this should work if you have setuptools / easyinstall already in hand for your python:: $ bin/easy_install -f http://download.zope.org/distribution \ zope.pagetemplate That gets all the transitive dependencies, too:: $ ls lib/python2.4/site-packages/ easy-install.pth pytz-2005r-py2.4.egg setuptools-0.6c5-py2.4.egg setuptools.pth zope.component-3.4dev_r72903-py2.4.egg zope.deferredimport-3.3dev_r72527-py2.4.egg zope.deprecation-3.3dev_r72532-py2.4.egg zope.event-3.3dev_r72545-py2.4.egg zope.i18n-3.3dev_r72550-py2.4.egg zope.i18nmessageid-3.4dev_r72562-py2.4-linux-i686.egg zope.interface-3.4dev_r72681-py2.4-linux-i686.egg zope.pagetemplate-3.3dev_r72906-py2.4.egg zope.proxy-3.4.0a1-py2.4-linux-i686.egg zope.schema-3.3dev_r72571-py2.4.egg zope.tal-3.3dev_r72583-py2.4.egg zope.tales-3.3dev_r72584-py2.4.egg And it works:: $ bin/python Python 2.4.3 (#2, Oct 6 2006, 07:52:30) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from zope.pagetemplate.pagetemplatefile import PageTemplateFile >>> Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF9sAk+gerLs4ltQ4RAlomAKCpt3VJUKFIfDW3lImSBWla2NwFHwCgwjtd ceuqPEUUiVkgJ9KgCNc79ZM= =217i -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Proposal for optimized Blob handling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sidnei da Silva wrote: > On 3/7/07, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: >> Am I the only person here who immediately associated "link" with the >> POSIX? Also, am I the only one who read "when possible" as "when on a >> POSIX system where link is available", in other words, "when not on >> Windows"? One starts to wonder... > > NTFS does support hard links since version 5, which means Windows > 2000+. It does not support hard links to directories though, only soft > links (which are called junctions or junction points). The version of > NTFS shipped with Vista supports hard links for directories I believe. POSIX systems don't allow hard links to directories, either, in practice:: $ man ln ... -d, -F, --directory allow the superuser to attempt to hard link directories (note: will probably fail due to system restrictions, even for the superuser) Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF76hn+gerLs4ltQ4RArm3AJ9o6Vw63qc6cJT3GPJOVebCFhDtiACfViDa EI1MxpxIIwEQl3uXVxly7M4= =NZUy -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: zope.app.form generates invalid HTML
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin Aspeli wrote:
> Hi guys,
>
> I'm pretty sure you're not allowed dots in ids of HTML elements.
The attached HTML and XHTML pages both pass the W3C validator (one HTMl
4.01 strict, the other XHTML 1.0 strict). Both use dotted IDs for form
elements. Neither renders "properly" in Firefox 1.5 (the selectors
based on the dotted ID, as well as those based on attribute, don't get
applied the form elements).
> At
> least not when they are prefixed by 'form'. A zope.schema.TextLine in a
> formlib form, for example, generates HTML like this:
>
>
>
> In particular, we want to style the fields to look a bit more like
> Plone, and we have special cases for "title" and "description" that we
> want to style by ID, not class.
>
> However, CSS like this has no effect in Firefox or Safari:
>
> #form.title {
> font-size: 160%;
> font-family: ;
> font-weight: normal;
> width: 99%;
> }
> #form.description {
> font: 100% ;
> font-weight: bold;
> height: 6em;
> width: 99%;
> }
>
> Not all that surprising - it could look like I'm styling a form with
> class="description".
Not according to the CSS specs. Note that we might be better off making
it easy to place a custom CSS class on the widget, rather than fighting
browser failures on various other selectors.
> I then hacked zope.app.form.widget's renderElement() function to look
> like this:
>
> def renderTag(tag, **kw):
> """Render the tag. Well, not all of it, as we may want to / it."""
>
> if 'id' in kw:
> kw['id'] = kw['id'].replace('.', '-')
>
> ...
>
> The tests in zope.app.form still pass.
>
> Hacky, but the alternatives are to (a) override all the widgets or (b)
> at least provide custom ones only for the purpose of getting stylable
> ids on various fields. renderTag() is called from a lot of places with
> id=self.name. We could fix all those, too, of course.
>
> I would be happy to submit a patch for either the explicit check in
> renderTag() or for changing all calls to this in zope.app.form.
>
> However, if someone has depended on the ids being with dots (possibly
> not quite as likely as it may seem, since these forms are typically
> auto-generated) then we may not have a decent way of deprecating that.
The most likely breakage is going to be in Javascript using
'getElementById'.
- -1 on changing the default behavior; to paraphrase, "broken browsers
you will have always with you."
+1 on changing 'renderTag' to use some kind of "local" policy (e.g.,
look up an 'ITagElementCleaner' utility) to spply such transforms.
E.g.::
def renderTag(tag, **kw):
cleaner = querytUtility(IWidgetTagCleaner)
if cleaner is None:
kw = cleaner(kw)
...
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD4DBQFF3tJ9+gerLs4ltQ4RAlwdAJ4hSxBGsrHAYvrxqFTCXXLfeAdSMgCWLUxR
mKehOrvyy9SF+z91PS6hHw==
=Cr9R
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Checkins mails and zope egg changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Baiju M wrote: > Jim Fulton wrote: >> On Feb 15, 2007, at 3:02 AM, Baiju M wrote: >> >>> Hi, I am not getting any changes (through checkins mailing list) >>> made to zope eggs recently by 'alex' (committer id) >>> >>> alex, I read your commit mesage: "Remove setup.cfg.in, INSTALL.txt, >>> CHANGES.txt, test.py, MANIFEST.in and README.txt because they are >>> no longer needed." >> Could you remind me which package (or svn revision) you are refering >> to? > > *r72589, **r72588 and few others.* > >>> Why these files are no longer needed? test.py may not be required >>> after buildout. >> I'll turn that around. What are they needed for? You should only >> need a setup.py and, if buildout is used, a buildout.cfg. >> >> The examples alex showed me seemed out of date with the current way >> of doing things. >> >> I particularly don't want setup.cfg.in, and MANIFEST.in as these >> aren't really necessary and tend to cause problems. > > Agreed. Anyway, atleast we will be required a README.txt and CHANGES.txt I would argue that those belong in the *package*, not in the "building" directory (the one containing 'setup.py'), because they are relelvant to users of the built egg, not just to the developer who checks out the whole thing. I know that distutils / setuptools complain if they find no 'README.txt ' next to setup.py: I ususally have a nearly empty one pointing "down" to the real one. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF1GhL+gerLs4ltQ4RAq2MAKC36pbnsij9o0m9Gz1KuxbSGsjCCQCgp6yQ b0bL/PexB1ZcRzFJe3BoykQ= =y/Qw -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: calling interface returns object, calling queryAdapter returns None?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Withers wrote:
> Fred Drake wrote:
>> On 1/24/07, Chris Withers <[EMAIL PROTECTED]> wrote:
>>> queryAdapter, for me, is "starting with the supplied object, get me
>>> something that implements the supplied interface and return None if no
>>> such object can be obtained".
>> o = IFoo(ob, None)
>> if os is not None:
>
> Ah, now that's what I was looking for, thanks :-)
Note that for regularity, I assert that the calling the IFoo interface
should allow the follwing use cases, based on the asserition that
utilities are "zero-order" adapters, just as views are "binary order"
adapters.
First the setup::
>>> from zope.interface import Interface, Attribute
>>> from zope.interface import implements, directlyProvides
>>> from zope.component import provideUtility, provideAdapter, adapts
>>> class IFoo(Interface):
... name = Attribute(u'Name')
>>> class FooUtil:
... implements(IFoo)
... def __init__(self, name):
... self.name = name
>>> fooUtil = FooUtil('default')
>>> provideUtility(fooUtil)
>>> fooUtilNamed = FooUtil('named')
>>> provideUtility(fooUtilNamed, name='named')
>>> class FooAdapter:
... implements(IFoo)
... adapts(None)
... name = 'default'
... def __init__(self, context):
... self.context = context
>>> class FooAdapterNamed(FooAdapter):
... name = 'named'
>>> provideAdapter(FooAdapter)
>>> provideAdapter(FooAdapterNamed, name='named')
Now the usage. Things which *don't* work today are marked '(SF)'.
Interfaces called with *no* context argument return
utilities, not adapters (SF)::
>>> u_default = IFoo() # return the default utility
>>> u_default.__class__.__name__, u_default.name
('FooUtil', 'default')
Named utilities can also be looked up (SF)::
>>> u_named = IFoo(name='named')
>>> u_named.__class__.__name__, u_named.name
('FooUtil', 'named')
Default adapter lookup works as expected::
>>> context = object()
>>> a_default = IFoo(context)
>>> a_default.__class__.__name__, a_default.name
('FooAdapter', 'default')
But we can also do named adapter lookup (SF)::
>>> a_named = IFoo(context, name='named')
>>> a_named.__class__.__name__, a_named.name
('FooAdapterNamed', 'named')
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFuAt/+gerLs4ltQ4RAmTSAJ0SYhaKb3fPrpeIm1odC02LrbjZuQCfXK/0
NMERLbcjZsBK77OeCWUACYQ=
=wI8F
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: wildcard adapter
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Withers wrote: > Marius Gedminas wrote: >> Now when you try to adapt anything to ITest, zope.component will call >> your ``adapter`` function and then check the return value. A return >> value of None means "the adapter is not available", and results in a >> TypeError you see here: > > Yes, apologies, both you and Philipp are correct, I was trying to show a > simple version of a problem and oversimplified. > > Here's what I really meant: > > >>> from zope.component import provideAdapter > >>> from zope.interface import Interface > >>> from zope.component import getMultiAdapter > >>> class ITest(Interface): pass > ... > >>> def adapter(*args): return args > ... > > >>> provideAdapter(adapter,adapts=(None,),provides=ITest) > >>> ITest(1) > (1,) > > Yay, as expected... > > >>> getMultiAdapter((1,),ITest) > (1,) > > Good, still works... > > >>> provideAdapter(adapter,adapts=(None,None),provides=ITest) > >>> getMultiAdapter((1,1),ITest) > Traceback (most recent call last): > ... > zope.component.interfaces.ComponentLookupError: > ((1, 1), , u'') > > Oh dear, what have I done wrong here? The "order" of your adapter registration is *one*, but you are trying to look it up against *two* objects (like a view). Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFsSp++gerLs4ltQ4RApjSAKCYZwOp8b7LlUYEdk5E54bMSStY+ACgzdRY 8ZKbrbRcpyGUhel5YXXeuw4= =nAls -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: server error in apidoc (encoding pb)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christophe Combelles wrote:
> Did someone have a look on this error ? Is it a trivial thing, or a local
> configuration problem, or is it reproduceable?
> (I write in utf-8, and I put # -*- coding: utf-8 -*- in my interfaces.py)
>
> Christophe
>
>
> Christophe Combelles a écrit :
>> Hello,
>>
>> When I put some accentuated character in the docstring of an interface
>> and I want to see the interface doc in
>> apidoc->interfaces->search->IMyInterface,
>>
>> I then get a server error:
>>
>>
>> File "/usr/lib/python2.4/site-packages/zope/tales/tales.py", line 696,
>> in evaluate
>> return expression(self)
>>- /usr/lib/zope3/lib/python/zope/app/apidoc/ifacemodule/index.pt
>>- Line 23, Column 4
>>- Expression:
>>- Names:
>> {'args': (),
>>'context': > zblog.category.interfaces.ICategoryContainer>,
>>'default': ,
>>'loop': {},
>>'nothing': None,
>>'options': {},
>>'repeat': {},
>>'request': > URL=http://localhost:9673/++apidoc++/Interface/zblog.category.interfaces.ICategoryContainer/index.html>,
>>
>>
>>'template':
>> > at 0xb6a319ac>,
>>'usage': > 0xb5c3ea4c>,
>>'view': > from /usr/lib/zope3/lib/python/zope/app/apidoc/ifacemodule/index.pt
>> object at 0xb5c3ef4c>,
>>'views': > object at 0xb5bf9d6c>}
Please give us the *full* traceback: we can't even see what error is
occuring here, except that something is going wrong in 'view/getDoc'.
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFrPIA+gerLs4ltQ4RAj2tAJ9o5wySWu5nD94p2iF2Ht2K+mlc6gCgz4RY
ZwgDhICeKxd2uX3ZF1fEZOg=
=2ejP
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: zope.tal.xmlparser.XMLParser() dislikes unicode
s the user > may be tempted by the ability to use encoding="" to paste latin-1 XML > text. Editor could say it only wants it in whatever encoding the page is > in, though. > > Martijn Faassen proposal > > > If you rip out the encoding before data is stored in the page template > and then store as unicode, then we have the following cases: > > A) FTP download: Encode to UTF-8, output in UTF-8 only. No encoding > mangling necessary. > > B) FTP upload: read encoding="" bit and decode to unicode accordingly. > Rip out encoding="". Could be done by a parse/serialization step, then > decode result to unicode. > > C) parse: encode to UTF-8 just before entering the parser. > > D) publisher download: Encode according to response header or zope.conf. > Add in encoding="" if output is non-UTF-8 using XML names for encoding. > > E) ZPT inclusion: send unicode text to the page template. No encoding="" > bit will be in the XML presented in the editor. > > F) form submit: Rip out any encoding="" before storing, ignoring it as > XML was in output encoding, then convert to unicode using input encoding. > > encoding="" removal: B, F > encoding="" adding: D > encoding="" reading: B > encode from unicode: A, C, D > decode to unicode: B, F > > no encoding="" manipulation required: A, C, E > no recoding required: E > straightforward: E > > No storage of encoding information on ZPT object is necessary. > > Case B) potentially confusion as upon re-download XML document will be > recoded to UTF-8 (though XML editors should be able to deal with this as > it's the default). > > Form edit still potentially confusing as encoding="" bit disappears, but > at least suggestion to user is not made that information *presented* in > a textarea is in a particular encoding specified in the encoding="" bit. > > Tres Seaver proposal (speculation) > == > > Storage in UTF-8. > > A) FTP download: output in UTF-8 only, can be done directly. > > B) FTP upload: read encoding="" bit and, if not UTF-8, decode to unicode > accordingly. Then recode to UTF-8. Rip out encoding="". Could be done by > an XML parse/serialization step. > > C) parse: just pass UTF-8 to parser. > > D) publisher download: Decode to unicode. Then recode to desired output > encoding (with XML names for encoding added in encoding="") bit. > > E) ZPT inclusion: Decode text to unicode. No encoding="" bit will be in > the XML presented in the editor. > > F) form submit: Rip out any encoding="" before storing, ignoring it as > XML was in output encoding, then convert to unicode using that encoding, > then convert again to UTF-8. > > encoding="" removal: B, F > encoding="" adding: D > encoding="" reading: B > encode from unicode: B, D, F > decode to unicode: B, D, F > > no encoding="" manipulation required: A, C, E > no recoding required: A, C (B and F if UTF-8 uploaded) > straightforward: A, C > > No storage of encoding information in ZPT object is necessary. > > Case B) potentially confusion as upon re-download XML document will be > recoded to UTF-8 (though XML editors should be able to deal with this as > it's the default). > > Form edit still potentially confusing as encoding="" bit disappears, but > at least suggestion to user is not made that information *presented* in > a textarea is in a particular encoding specified in the encoding="" bit. > > Just store the XML text > === > > Storage XML text literally as received. Maybe this is actually what Tres > meant. :) > > A) FTP download: output can be done directly. > > B) FTP upload: store input directly > > C) parse: just pass text to parser. > > D) publisher download: Decode to unicode using encoding="" bit. Remove > encoding bit. Then recode to desired output encoding (with XML names for > encoding added in encoding="") bit. > > E) ZPT inclusion: Decode text to unicode using encoding="" bit. > > F) form submit: Encode text in form from unicode according to > encoding="" bit. > > encoding="" removal: D > encoding="" adding: D > encoding="" reading: B, D, E, F > encode from unicode: D, F > decode to unicode: D, E > > no encoding="" manipulation required: A, C (but B, E, F only reading) > no recoding required: A, B, C > straigh
[Zope3-dev] Re: zope.tal.xmlparser.XMLParser() dislikes unicode
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
> Tres Seaver wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Andreas Jung wrote:
>>> --On 14. Januar 2007 18:14:45 + Chris Withers <[EMAIL PROTECTED]>
>>> wrote:
>>>
>>>> Dieter Maurer wrote:
>>>>> A halfway intelligent parser would accept Unicode when it gets it
>>>>> and concentrate on the remaining part of its task: either reporting
>>>>> structural events or building a parse tree.
>>>> The trivial fix I use in Twiddler is as follows:
>>>>
>>>> if isinstance(source,unicode):
>>>>source = source.encode('utf-8')
>>>>
>>>> Of course, this assumes a heading of either >>> encoding="utf-8"?> or a missing encoding attribute, in which case the xml
>>>> spec states that the string must be utf-8 encoded.
>>> The encoding of the XML preamble should not matter when parsing a XML
>>> document stored as unicode string.
>> That encoding is a *lie*, which is the real problem. Parsers expect it
>> to be *correct*, and if missing, expect the text to be encoded as UTF-8,
>> per the spec (if the document comes from an HTTP request, then the
>> application may supply the encoding from the request headers).
>>
>> Nothing in the XML specs allows or specifies and behavior for XML
>> documents serialized as unicode, becuase such serializations are
>> *programming language specific*.
>
> While I agree that the encoding declaration is ambiguous at best and
> should be rejected, you can find a bit in the spec which supports XML as
> Python unicode strings. A Python unicode string can be seen as a string
> with "external character encoding information": it's the native encoding
> of Python. Therefore we can make sense of it in an XML parser. For my
> previous analysis of the spec see here:
>
> http://codespeak.net/pipermail/lxml-dev/2006-May/001137.html
>
> What however is bad and evil is to just ignore conflicting encoding
> declarations in an XML document itself. I'd choose either one of:
>
> * bail with a clear error when unicode is supplied at all
>
> * bail with a clear error when unicode is supplied with any explicit
> encoding declaration in the XML.
>
>>> It is of importance as soon as you
>>> convert the document back to a stream e.g. when we deliver the content
>>> back to a browser or a FTP client. The ZPublisher (for Zope 2) deals with
>>> that by changing the encoding parameter of the preamble for XML documents
>>> based on the desired output encoding. utf-8 is always a good choice however
>>> other encodings like iso-8859-15 might raise UnicodeDecodeErrors. The Zope 2
>>> publisher "avoids" this problem converting the unicode result using
>>> errors='replace' (which is likely something we might discuss :-))
>> Unicode XML is not only problematic for streaming. For instance, you
>> *can't* pass a Unicode string to the libxml2 *at all* , unless you want
>> a core dump. The API requires that you pass it strings encoded as UTF8.
>
> You can in lxml. :) libxml2 as a C API doesn't even support any unicode
> string type as far as I am aware.
It *requires* UTF-8-encoded strings. See http://xmlsoft.org/xml.html
12. So what is this funky "xmlChar" used all the time?
It is a null terminated sequence of utf-8 characters. And only
utf-8! You need to convert strings encoded in different ways to
utf-8 before passing them to the API. This can be accomplished
with the iconv library for instance.
Frankly, I don't get the desire to *store* a complete XML document (as
opposed to the extracted contents of attributes or nodes) as unicode:
it isn't as though it can be easily processed in that form without
re-encoding (even if lxml is the one doing the re-encoding). It isn't
"discourse", in the Zope3 sense of "text intended for human
consumption", and the tools people use with it are all going to expect
some kind of validly-encoded string.
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFq/ix+gerLs4ltQ4RAmkTAJ9ifMH37TNyfZXo+v5zvXCsrFXIXQCfZFow
GBTndXG+0Gw9OnAZeNCxADs=
=Yr7F
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: zope.tal.xmlparser.XMLParser() dislikes unicode
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andreas Jung wrote:
>
> --On 14. Januar 2007 18:14:45 + Chris Withers <[EMAIL PROTECTED]>
> wrote:
>
>> Dieter Maurer wrote:
>>> A halfway intelligent parser would accept Unicode when it gets it
>>> and concentrate on the remaining part of its task: either reporting
>>> structural events or building a parse tree.
>> The trivial fix I use in Twiddler is as follows:
>>
>> if isinstance(source,unicode):
>>source = source.encode('utf-8')
>>
>> Of course, this assumes a heading of either > encoding="utf-8"?> or a missing encoding attribute, in which case the xml
>> spec states that the string must be utf-8 encoded.
>
> The encoding of the XML preamble should not matter when parsing a XML
> document stored as unicode string.
That encoding is a *lie*, which is the real problem. Parsers expect it
to be *correct*, and if missing, expect the text to be encoded as UTF-8,
per the spec (if the document comes from an HTTP request, then the
application may supply the encoding from the request headers).
Nothing in the XML specs allows or specifies and behavior for XML
documents serialized as unicode, becuase such serializations are
*programming language specific*.
> It is of importance as soon as you
> convert the document back to a stream e.g. when we deliver the content
> back to a browser or a FTP client. The ZPublisher (for Zope 2) deals with
> that by changing the encoding parameter of the preamble for XML documents
> based on the desired output encoding. utf-8 is always a good choice however
> other encodings like iso-8859-15 might raise UnicodeDecodeErrors. The Zope 2
> publisher "avoids" this problem converting the unicode result using
> errors='replace' (which is likely something we might discuss :-))
Unicode XML is not only problematic for streaming. For instance, you
*can't* pass a Unicode string to the libxml2 *at all* , unless you want
a core dump. The API requires that you pass it strings encoded as UTF8.
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFq9wf+gerLs4ltQ4RAvBkAKCGZke7HHr7vWQKcwn5IHW93GHlFQCgyXMJ
a+vZYi2VRnZTt1XBt7O6U3Y=
=+i3B
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
