[Zope3-dev] Re: [Zope-dev] I'd lobe to merge the zope3-dev and zope-dev lists
Previously Jim Fulton wrote: Any objections? This would basically involve retiring the zope3-dev list and moving zope3 developers to the zope-dev list. +1 Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] faulty releases and pypi access
Previously Stephan Richter wrote: I totally disagree. If we trust people with repository access, then we have to trust them with release making. If you subscribe to the egg process, you have to do frequent releases. Why would eggs require more frequent releases? Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] faulty releases and pypi access
Stephan Richter wrote: On Wednesday 26 September 2007 09:20, Wichert Akkerman wrote: Previously Stephan Richter wrote: I totally disagree. If we trust people with repository access, then we have to trust them with release making. If you subscribe to the egg process, you have to do frequent releases. Why would eggs require more frequent releases? Have you tried working with a pure egg-based project? It's unavoidable. I have worked on large projects where you had modules and you could only use released versions. I don't see the problem. Wichert. -- Wichert Akkerman [EMAIL PROTECTED] It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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: z3c.widget not on pypi?
Previously Stefan H. Holek wrote: I fully agree that such eggs should not have been released into the wild. It is just that, down here in real-life, these eggs *have* been released, and their versions *have* been nailed (not nailing the versions of *all* eggs means saying goodbye to the idea of reproducible buildouts). By deleting a released egg (as opposed to superseding it with a good version) one potentially creates a lot of pain for a lot of people. I can fully see a reason to need a private tag or dev-release egg for a project. But you can put those in a private repository for that project. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] z3c.widget not on pypi?
I noticed that z3c.widget has a tagged release on svn but there is no cheeseshop entry for it. Is that on purpose? It would be practical to have it registered there. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] z3c.widget not on pypi?
Jodok Batlogg wrote: On 18.09.2007, at 23:29, Wichert Akkerman wrote: I noticed that z3c.widget has a tagged release on svn but there is no cheeseshop entry for it. Is that on purpose? It would be practical to have it registered there. you bring up an interesting point... the current practice (at least here at lovely systems, and presumably a lot of other developers) is to add download.zope.org/distribution (or a mirror of it) to your find-links. recently some people started registering packages (and uploading eggs ) to cheeseshop. this makes totally sense for zc.buildout, lovely.buildouthttp,... but i'm not sure about zope packages. because of this mix you might end up in getting the wrong egg. or not finding a egg you downloaded a few days ago. in case pypi is down you're totally stuck. well, i understand that the stability of pypi is much better lately and the simple interface, the and ppix mirrors make the index lookup much faster as well. but for me there are still two remaining issues: - the eggs are hosted on cheesehop as well, it's not easy (commandline) to host the egg externally or to specify a mirror to use when pulling the eggs. that's not acceptable for production deployments. You can upload to both the cheeseshop and another place you list in find-links and one will act as a fall-back for the others. Since uploading to the cheeseshop is so trivial that should be little to no extra effort. - by default setup.py sdist bdist_egg register upload hides the old releases, which is not acceptable as we nail all versions for deployments. if someone releases a new version, the older ones disappear and buildout (with nailed versions) stops and complains not finding the egg. That's not true, is it? If I remember correctly it is only hidden from the user-friendly web interface. The simple index as used by buildout and setuptools stills sees the older versions. Wichert. -- Wichert Akkerman [EMAIL PROTECTED] It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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.sendmail having dependency on zope.app.comonent
Previously Marius Gedminas wrote: On Fri, Aug 31, 2007 at 01:21:08PM +0200, Christian Theune wrote: Am Freitag, den 31.08.2007, 13:06 +0200 schrieb Wichert Akkerman: Is there documentation on sources anywhere? The last time I checked there was nothing that I could understand either in zope.* or on the wiki. It took me a while to understand them myself. Especially as there is some code in there that is basically not useful. I'll try to give a very short overview: How do you feel about adding it to the top of zope/schema/sources.txt? I've added it there now. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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
Tres Seaver wrote: -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). 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. Wichert. -- Wichert Akkerman [EMAIL PROTECTED] It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Known working sets
Previously Philipp von Weitershausen wrote: Proposal I think zc.buildout's version mechanism in buildout.cfg is a good technical basis. It's simple, light-weight and easy to version-control. For example, the Grok project could create a grok-0.11.cfg defining the known working set for the Grok 0.11 release, with the following contents:: [grok-0.11] grok = 0.11 ZODB = 3.8.0 zope.component = 3.4.0 ... Then, the Grok folks could distribute this file and everybody who wanted to use Grok 0.11 would simply have to put the following two lines into their buildout.cfg:: [buildout] ... extends = grok-0.11.cfg versions = grok-0.11 With this, it'll be easily possible to switch to a newer version of e.g. ZODB3 by overriding the setting in buildout.cfg:: [buildout] ... extends = grok-0.11.cfg versions = grok-0.11 [grok-0.11] ZODB = 3.9.0 # this overrides whatever is set in grok-0.11.cfg 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? Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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.sendmail having dependency on zope.app.comonent
Previously Philipp von Weitershausen wrote: On 30 Aug 2007, at 14:19 , Michael Howitz wrote: Am 22.08.2007 um 15:53 schrieb Philipp von Weitershausen: Michael Howitz wrote: while looking at the dependencies of packages in the zope.* namespace at gocept we found out that zope.sendmail depends on zope.app.component. Just to make sure: If we ever had a formal distinction of the zope.* and zope.app.* namespaces, I think we've abandoned it a while ago already. So, it doesn't matter whether a package is in zope.* or zope.app.*, we need to take all interdependencies (also the ones in zope.app.*) into account. So all in all I don't think it's a big problem in zope.sendmail depended on zope.app.component, as long as zope.app.component wouldn't depend on a gazillion other things... So, you suggest to leave this dependency as it is as long no-one complains? In general, yes. That said, zope.app.component isn't the lightest dependency. It draws in almost all of zope.app.* zope.sendmail needs zope.app.component.vocabulary.UtilityVocabulary to define a vocabulary for the utilities implementing zope.sendmail.interfaces.IMailDelivery. So we'd suggest to move zope.app.component.vocabulary.UtilityVocabulary out of the zope.app.* namespace because it is a generic vocabulary. Possible places for UtilityVocabulary could be zope.component (because the concept of utilities is defined there) or zope.schema (because the concept of vocabularies is defined there). zope.schema seems to be the better place because zope.component does not depend on zope.schema yet. But zope.schema does in no way depend on zope.component. Yes, you are right. So we would introduce a dependency from zope.schema to zope.comonent. The only way to get lost of the zope.app dependency seems to be a new package zope.app.sendmail (including deprecation!). But there is already a zope.app.mail which is deprecated and will be removed in 3.5. I don't understand why that is the only way and why we have to create more packages in that dreadful zope.app.* namespace. One way to break this dependency is to move the UtilityVocabulary out to a separate package, e.g. zope.utilityvocabulary. Another way is to simply stop using UtilityVocabulary; this would also be an opportunity to replace it with a source. zc.sourcefactory is supposed to make this quite easy (and from what I've seen, it does), but unfortunately its dependencies aren't exactly light-weight either. Is there documentation on sources anywhere? The last time I checked there was nothing that I could understand either in zope.* or on the wiki. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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: [StabilizeEggPackages] (edit) Is that all that has to be done in setup.py?
Previously Fred Drake wrote: On 8/29/07, srichter [EMAIL PROTECTED] wrote: ++added: - Ensure that the setup.py has a decent set of meta-data, in particular: * The long_description contains all doctests. I know Jim's advocated this, at least for all documentation-centric doctests, but I don't know that we've reached a consensus on this. What do others think? I really don't like long PyPI pages myself; a few paragraphs seems sufficient, and is certainly more in line with the original intent of the long description field. I don't like the overly long PyPI pages, but I do really like having easily browsable documentation online. PyPI is the only places where that is possible at the moment. Pointing people to svn.zope.org to read documentation is not an option in my opinion: finding and reading documentation would require a dozen extra mouseclicks. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] zalchemy broken on the cheeseshop
At the moment zalchemy is making buildout complain about connection errors. The problem is that on http://cheeseshop.python.org/simple/z3c.zalchemy there is a link to https://svn.zope.org.repos/main which does not exist: there is no .repos top level domain. I also remember Christian saying that 0.2 was not finished, perhaps it should be removed from the cheeseshop as well? Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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: SVN: zope.location/trunk/setup.py using pypi as homepage instead of svn.zope.org
Previously Stephan Richter wrote: On Saturday 18 August 2007 17:03, Philipp von Weitershausen wrote: * Please also don't forget to add a changelog entry in README.txt, especially if you're adding features. If there's no README.txt yet, this is a good time to give it one. It should start out with a simple paragraph and have at least one section called Changes. You could then use its contents as the long_description in setup.py. Other packages (e.g. zope.proxy or zope.publisher) can serve as examples. Why do the changes have to be part of the README file? That seems no good. I think a separate file is much better. +1 The audience for changelog information is different than the audience for normal documentation. If you really want to you can combine both files in the long_description from your setup.py. That can make your cheesehop package page overly large though. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Add function for schema validation in zope.schema
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.
Wichert.
--
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] z3c.zalchemy tag missing?
The cheeseshop lists a 0.2 version of z3c.zalchemy but in subversion I only see tags for 0.1 and 0.1.1. svn trunk lists 0.2 as unreleased in CHANGES.txt. What is the status of z3c.zalchemy 0.2? Is it really released, or does the cheeseshop show what is really a development snapshot as 0.2? Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] copied doctest in z3.zope3recipes for Windows support
Previously Martijn Faassen wrote: Hi there, I don't have any Windows knowledge, so my ability to review Roger's changes to add (much needed!) windows support to z3.zope3recipes is limited. I do however notice that an entire doctest was more or less copied verbatim: README.txt got copied to WINDOWS.txt. The Windows version has some changes, and a few additions, but it's almost exactly the same. Now if these were unit tests this would be less problematic, but this is a document as well, and as a result we now have two virtually identical documents to maintain. That seems wrong. I don't understand that. Having to maintain duplicate unit tests or duplicate documents sounds like the exact same amount of duplicate work and problems to me. Why do you consider duplicate documents to be more problematic? Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] 'thread_local' AttributeError in zope.security.checker
Previously 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 see the same thing: create a new project with grokproject, run bin/zopectl fg and it aborts with that error. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: zope.security problems related to Python 2.5 update? (Was: [Zope3-dev] Removed zope.security 3.4b4)
Previously Christian Theune wrote: 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. This is deeper than I thought. b3 doesn't work either. It looks like the merge from the branch with support for Python 2.5 is causing the problems. I can confirm that the last release before the python 2.5 support was added (3.4.0-b2) works correctly. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] 'thread_local' AttributeError in zope.security.checker
Previously 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. Here you are: [snow;/tmp/test]-119 bin/zopectl fg /tmp/test/parts/app/runzope -C /tmp/test/parts/zopectl/zope.conf Traceback (most recent call last): File /tmp/test/parts/app/runzope, line 97, in ? import zope.app.twisted.main File /home/wichert/buildout-eggs/tmp-GMMRj/zope.app.twisted-3.4.0b1_r76119-py2.4.egg/zope/app/twisted/main.py, line 32, in ? File /usr/lib/python2.4/site-packages/PIL/__init__.py, line 22, in ? File /home/wichert/buildout-eggs/tmpzGONPg/zope.app.appsetup-3.4.0a1-py2.4.egg/zope/app/appsetup/appsetup.py, line 25, in ? File /home/wichert/buildout-eggs/tmpG_NQ4q/zope.security-3.4.0b3-py2.4-linux-i686.egg/zope/security/management.py, line 25, in ? File /home/wichert/buildout-eggs/tmpG_NQ4q/zope.security-3.4.0b3-py2.4-linux-i686.egg/zope/security/checker.py, line 420, in ? AttributeError: 'module' object has no attribute 'thread_local' Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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: Windows eggs
Previously Marius Gedminas wrote: - Unit tests: there are many of those, they're independent (thus a single .txt for a collection of tests is a Bad Idea), they're short (so understanding and debugging is easy) and expressive. I put those into .py files full with functions that look like def doctest_FooClass_does_this(): Test that FooClass is able to ... foo = FooClass() results = foo.do_this() for fruit, score, comments in results: ... print fruit.ljust(10), '|', score.ljust(5), '|', comments Orange | 9 | Tastes good, a bit sour Apple | 8 | Varies and have a traditional test_suite() function at the end that returns a DocTestSuite with the appropriate setUp/tearDown/optionflags. Until you have to step through the test with pdb, at which point it becomes very painful. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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: Windows eggs
Previously Tres Seaver wrote: -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. Amen. I find failing doctests to be much harder to debug as well. I use doctests as a method to make sure examples in my documentation are correct, which is very useful. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Don't need $Id$ string any more
Previously 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. Their major downside is that they cause a lot of polution when diffing trees. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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 egg dependencies and tests
Previously Christian Theune wrote: Well. This depends. If you want to enable eggs to work against unstable releases then you need to do 3.3, because: 3.3 3.4dev 3.4a 3.4(.0) But =3.4dev should always work, right? Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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: IKeyReference for files
Previously Martijn Faassen wrote: Wichert Akkerman wrote: Previously Uwe Oestermeier wrote: Martijn Faassen [EMAIL PROTECTED] schreibt: Now I'm hoping I'm missing some kind of strategy and perhaps someone will have a luminous idea to make this work without the creation of a separate index. Or if not, at least I can give up looking and just go and write that index. Does anyone have any suggestions? Hi Martijn, I have experimented with the inodes of files, which are a good candidate for IKeyReferences for files. Using inodes solves the problem that the ids should remain stable across moves. They are also a good basis for a detection of moves which happen outside the control of Zope. Unfortuantely there are filesystems without usable inode numbers (or inodes). You also need to take multiple filesystems into account, which means you need to include the device major and minor number in your key. This leads to another problem: those numbers may not be stable across reboots. Not stable across reboot would be bad. This needs to work minimally under Linux and Windows. Linux makes no strong guarantees. Especially for devices which can appear on different busses or bus slots (USB, firewire, iSCSI) the block numbers can change. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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: Zope3 Standalone Page Templates
Previously Duncan McGreggor wrote: On 3/13/07, Tres Seaver [EMAIL PROTECTED] wrote: I still get a crazy amount of packages installed when I do this (see below). Either I'm doing something wrong (any ideas?) or I've got a very different definition of stand-alone ;-) Personally I, and from what I can see most people, use SimpleTAL (http://www.owlfish.com/software/simpleTAL/) if I need to use TAL outside of Zope. It's very small and has no dependencies. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Proposal for optimized Blob handling
Previously Christian Theune wrote:
Am Mittwoch, den 07.03.2007, 21:31 +0100 schrieb Uwe Oestermeier:
Christian Theune [EMAIL PROTECTED] schreibt:
Nope. It won't disappear if you link it again. And the link(src, dst)
does move it to a 'save' location ;)
Again I'm not convinced because you cannot be sure that no other process
deletes the temp file.
In the following I simulate this with a os.system call:
import tempfile, os
d = tempfile.NamedTemporaryFile()
os.path.exists(d.name)
True
d.write('Test')
os.path.exists('/tmp/asdf')
False
os.link(d.name, '/tmp/asdf')
d.close()
os.system('rm /tmp/asdf')
0
os.path.exists('/tmp/asdf')
False
open('/tmp/asdf').read()
Traceback (most recent call last):
File stdin, line 1, in ?
IOError: [Errno 2] No such file or directory: '/tmp/asdf'
Nope this is not the correct simulation. Who except your application
knows about /tmp/asdf? You have to simulate deleting d.name and then
you'll see that /tmp/asdf does not disappear.
The link operation *is* the rename except that now two files link to it.
This keeps the semantics of a NamedTemporaryFile in respect to the
request processing and the publisher intact.
Two possible things come to mind:
- if the tempfile is on a different filesystem you can not link the file
elsehere. Can we guarantee that they will be on the same filesystem?
- does this work on non-posix systems such as windows?
Wichert.
--
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
___
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: SOAP support?
Previously Roger Ineichen wrote: Hi Miklos If you can use REST, use it and forget all about SOAP. I guess SOAP API's will get replaced by REST in the near future. There is large amount of SOAP deployed and all the .NET development suites I'm familiar with make using SOAP really easy, so I expect to see SOAP used more rather than less. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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: SOAP support?
Previously Patrick Gerken wrote: On 1/8/07, Wichert Akkerman [EMAIL PROTECTED] wrote: There is large amount of SOAP deployed and all the .NET development suites I'm familiar with make using SOAP really easy, so I expect to see SOAP used more rather than less. As I dont work with .NET, can you outline how integration of soap services in a .NET application works, given I have a WSDL file and have to connect to such a server or provide such a service? As long as you use .net tools (like visual studio .net) you point the IDE to a WSDL file and it generates all the glue code for you and you can call it directly. That also works the other way around: you can add decorators to class methods and it automatically becomes a SOAP-accessible thing with a generated WSDL file (iirc it is generated runtime using introspection). As soon as you have to use SOAP from python you enter a world of pain. A few years ago ZSI was basically unusable. Judging by the traffic on the pywebsvcs list it is a lot better now, but a 2.0 release has been pending for well over a year now. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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: [SpringCleaning07]
Previously Jeff Shell wrote: If TAL / Page Templates isn't really made available to anyone else, how could it get momentum? 'zope.tal', 'zope.tales' and 'zope.pagetemplate' could probably be combined into a nice world-usable egg. With the right extras and entry points, they could be used with Buffet and then available to TurboGears, Pylons, web.py, whatever. There is a growing number of projects that use SimpleTAL. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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: Can an adapter find out what name it was registered for?
Previously Chris Withers wrote: Really? Certainly in Zope 2, prettymuch every persistent objects needs to be getId()'able... The fact that something is true in Zope 3 does not necessarily make it a good idea. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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: Can an adapter find out what name it was registered for?
Previously Stephan Richter wrote: On Wednesday 29 November 2006 03:37, Wichert Akkerman wrote: The fact that something is true in Zope 3 does not necessarily make it a good idea. But the chances are pretty high! ;-) Of course I meant to say 'Zope 2' there, which does reduce the chances. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.testing.testrunner: issue with remove_stale_bytecode
Previously Andrew Bennetts wrote: The real problem as you noted in your original message is that there's no way to distinguish between a pyc file that is only intended to be used as a cache of bytecode for a py file, and a pyc file that is intended to be used standalone. Isn't the existing or non-existing of a corresponding .py file a good indication? Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [ZF] Re: Use launchpad ! (was Re: [Zope3-dev] the maintenance of change logs)
Previously Martijn Faassen wrote: That's indeed a point to worry about. I can confirm having run into a spammed-to-death Trac in the path. Non-existant was a better description. This is not really a trac-specific problem though: any system which allows anonymous posting of content will suffer from spam at some point. For dev.plone.org we disabled anonymous ticket creation and modification. Since creating a plone.org is trivial that has not been a problem. Also, trac 0.10 has just been released which has some spam filtering hooks that might be useful. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [ZF] Re: Use launchpad ! (was Re: [Zope3-dev] the maintenance of change logs)
Previously Sidnei da Silva wrote: | This worries me a bit. Integration with svn seems to be a major | selling point of track, but you haven't done that. I'd like to see | a prototype that is actually integrated with our subversion repository. | What would be necesary to make that happen? Do you need actual access | to the local subversion files? Or can you access them remotely? Last I checked trac needed direct access to the local repository. It *might* be able to do remote access these days, but I wouldn't count on that. It depends on what you want: - in order to use the repository browser from trac trac needs filesystem access to the repository - for the commit/issue linking magic (commits automatically updating/closing tickets) pretty much any communication channel between a post-commit hook in the repository and trac can suffice. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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: Subversion 1.4 breaks mkzopeinstance.py
Previously Dmitry Vasiliev wrote: Ugh, it was me. I switched ZopeVersion from CSV to SVN, moreover the first revision (25322) used 're' module to parse .svn/entries and later (41452) has been switched to use 'xml.dom.minidom'. I think extract information from .svn/entries is more safe way than use svn info/svnversion but however it require more maintaining effort. So I'll change the parser to make it more robust if no one objects. I would suggest using svnversion first if that exists, and possibly doing a fallback to parsing things by hand. The output of svnversion is much more accurate than a single revision number. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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: Subversion 1.4 breaks mkzopeinstance.py
Previously Philipp von Weitershausen wrote: Jim Fulton wrote: Uh, why are we parsing the entries file? To get the current revision of the Zope 3 checkout... Why not use svn info --xml? Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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: Naming tags
Previously Rocky Burt wrote: On Mon, 2006-18-09 at 07:13 -0400, Jim Fulton wrote: On Sep 17, 2006, at 3:05 AM, Andreas Jung wrote: but not both and not mixed for the same version. My personal preference is 'rc'. My preference is c1. Not to be picky here, but using just 'c' I know of plenty of versioning schemas that use 1.0a, 1.0b, 1.0c, etc to represent bug releases. With 'rc' it doesn't conflict with any known versioning schemes that I'm aware of. -1 on c1 +1 on rc1 -1 on c1 and +1 on rc1 here as well, for the same reasons. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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: Release management refinements
Previously Anton Stonor wrote: Philipp von Weitershausen wrote: Shall we release once every 9 months from now on? 9 months pregnancy -- that's almost poetic. And painful to deliver? Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] selecting the translation domain in ZCML
Previously Jean-Marc Orliaguet wrote: this is OK for most use cases because packages manage their own domain, but there is a case which I don't know how to solve, i.e. when a package is supposed to register translations into another package's translation domain?. A po file includes its domain in its header; I'm assuming zope is smart enough to extract and use that. If not - please fix that :) Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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-dev] 64-bit BTrees
Previously Chris Withers wrote: The implicit change to make them all 64-bits which results in some unknown slowdown for all I BTree users seems a bit too scary to bite off... Has anyone done any benchmarks to prove that 64-bits is slower or faster? It would be interesting to see benchmarks on modern 32bit and a 64bit systems. Until then it's all hand-waiving. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Important Heads Up: I'm making IResult private
Previously Chris McDonough wrote: On Dec 26, 2005, at 8:51 AM, Jim Fulton wrote: Even on a unix-based platform on which the file is removed before data are written to it? For this project, yes, given that the project owners believe their business model depends on no sensitive unencrypted data ever being written to persistent storage (even temporarily). Can you transfer the data through a unix domain socket or a pipe? Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] unittest failure in svn trunk
I just noticed a unittest error on the current svn trunk: Failure in test testRunIgnoresParentSignals (zdaemon.tests.testzdrun.ZDaemonTests) Traceback (most recent call last): File /local/sources/svn/zope/Zope3/src/zdaemon/tests/testzdrun.py, line 237, in testRunIgnoresParentSignals self.assert_(is_started, spawned process failed to start in a minute) File /usr/lib/python2.3/unittest.py, line 278, in failUnless if not expr: raise self.failureException, msg AssertionError: spawned process failed to start in a minute Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] unittest failure in svn trunk
Previously Stephan Richter wrote: I always ignore this one ;-) If it is something to be ignored shouldn't be disabled? Having a known failure in the unittests is kind of bad. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] unittest failure in svn trunk
Previously Tim Peters wrote: See above. Does it fail often for you (or for Stephan)? If so, someone on a platform where it fails needs to investigate why. It certainly isn't failing for everyone. If failed 2 out of 2 tries on my laptop which uses python 2.3.5. I succeeded on a desktop system using python 2.4.1 Which suggests a possible pattern.. Using python 2.4.1 on my laptop works as well. And using python 2.3.5 on the desktop.. also works. Perhaps something starts a script as /usr/bin/python and switches back to python2.4 there? Could this issue be relevant? http://www.zope.org/Collectors/Zope3-dev/430 No, that item is fixed: the donothing script is properly marked as executable both in the svn repo and in my checkout. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
