ProfileVersions. Call
> purgeProfileVersions for base profiles:
> https://github.com/zopefoundation/Products.GenericSetup/pull/18
>
> I know, everyone is busy, no problem.
what exactly are you waiting for?
Cheers,
Yuppie
___
Zope-CMF mai
Hi Maurits,
Maurits van Rees wrote:
> Op 25-09-15 om 10:31 schreef yuppie:
>> But I hope these assertions are true:
>>
>> - a profile that depends on more than one base profile is broken anyway
>
> Agreed.
>
>> - if there is a base profile in the chain, it
Hi Maurits,
Maurits van Rees wrote:
> Op 24-09-15 om 13:54 schreef yuppie:
>> if you run a base profile in purge mode, you usually want to undo all
>> previous configuration and start from scratch. In theory you could do
>> that just with some setup handlers and
Hi Maurits,
Maurits van Rees wrote:
> Op 23-09-15 om 16:53 schreef yuppie:
>> if you run a base profile in purge mode, shouldn't that purge profile
>> versions automatically?
>
> GenericSetup itself is not doing this currently.
> It might be good to do that, but I
Hi Jens,
Jens W. Klein wrote:
> On 2015-09-22 12:30, yuppie wrote:
> [...]
>>> - pep8. This fixes over 6000 pep8 errors... Most of them fixed with the
>>> autopep8 command line tool. Small in scope yes, but due to all those
>>> errors a *very* large pull r
; rewrite Products/GenericSetup/tests/test_rolemap.py (64%)
>
> But I would say for the tests a 'git blame' is less needed.
Sorry, but I'm still not convinced.
I agree the negative effect is smaller in the tests. I would not object
if you make automated cleanups in tests b
reformatting that adds a lot of
noise if you use blame or similar techniques. And I use often diffs
between different versions to understand the history of the code.
There might be a subset of pep8 rules that is already respected in most
parts of the code and where fixing the rest wouldn't add m
> Meanwhile, is it okay to merge the current pull request and make a
> release? It seems that most people think it is okay, but yuppie is most
> on the fence.
No objections.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@zope.o
MFQuickInstaller, but that is going
> the way of the dodo. Slowly.
I didn't have a look at the Plone 5 control panel, but as you describe
it, something similar would be quite useful in the portal_setup UI. But
the Import tab has already too many options for rare use cases. It might
be better
al with.
>
> Some methods handle both 'normal' profiles and snapshots. With my
> changes, these now have:
> - if profile starts with 'snapshot-': do A.
> - elif profile starts with 'profile-': do B.
>
to figure out which kind of
profile we are dealing with.
Do you propose to make these namespaces obsolete in the code? Or only in
some places? How do I know if the profile_id argument requires the
prefix in a specific method?
Cheers,
Yuppie
___
Z
ot in sync with the version in the Subversion
repository.
And please don't forget the dev buildouts in http://svn.zope.org/CMF/.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
Maurits van Rees wrote:
> Can my branch be merged to trunk? And could we get a release please? I
> would appreciate it.
No objections from my side. Cheers, Yuppie
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinf
Hi Maurits,
Maurits van Rees wrote:
> 1. In January yuppie did a fix on GenericSetup trunk (r130476), which
> deserves a release, as it fixes upgrade step sort order with setuptools
> 8 and higher. Thank you, yuppie!
my fix was just a quick and dirty solution relying on legac
oposal for a second git
repository has to include a concept for keeping both repositories in sync.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-c
Matthew Wilkes wrote:
> I'd very much appreciate a release in the 2.2 series to make this code
> available to them (and others) without them having to pin their own
> release, what do others think?
No objections. Cheers, Yuppie
___
Zop
Hi!
yuppie wrote:
> http://svn.zope.org/?view=rev&revision=130422 changes the default value
> of DynamicType.portal_type from None to an empty string.
>
> getPortalTypeName returns this value and the interface still says:
>
> def getPortalTypeName():
> &
Hi!
yuppie wrote:
> I can't remember any decision to move the authoritative copy of
> Products.GenericSetup to the servers of GitHub Inc.
>
> So either the place for making authoritative decisions about
> Products.GenericSetup has also moved somewhere else or the canonical
&
None for uninitialized objects. We just have a
new requirement in Products.ZCatalog 3: Attributes with None values can
no longer be indexed.
Wouldn't it be better to adjust the portal_type just for indexing in the
IndexableObjectWrapper?
Cheers,
Yuppie
__
y was https://pypi.python.org/pypi/Products.GenericSetup/1.7.5
released from a different repository and why was this change made:
http://svn.zope.org/?view=rev&revision=130433 ?
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@zope.
Hi Jens!
Jens Vagelpohl wrote:
>
> On Oct 15, 2013, at 9:09 , yuppie
> wrote:
>
>> Jens Vagelpohl wrote:
>>> I have created a new release and uploaded it to PyPI.
>>
>> -2.2.8 (unreleased)
>> +2.2.8 (2014-10-15)
>>
>> You'
Jens Vagelpohl wrote:
> I have created a new release and uploaded it to PyPI.
-2.2.8 (unreleased)
+2.2.8 (2014-10-15)
You've got a time machine? Cheers, Yuppie
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listi
st recent call last):
> File
> "/usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7/unittest/case.py",
> line 331, in run
> testMethod()
CMF 2.2 requires Python 2.6, not 2.7.
Cheers,
Yuppie
___
n
if portal syndication is disabled. This is confusing.
- syndication.pt exists but is not used.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug
Hi Charlie!
Charlie Clark wrote:
> Am 01.08.2013, 11:46 Uhr, schrieb yuppie :
>> First a few words about names: CMF uses sometimes 'member area' and
>> sometimes 'home folder'. IMembershipTool has 'getHomeFolder' and
>> 'getHomeUrl' m
;Members Folder' and 'Home
Folder' allow to customize factories and behavior.
For existing sites you can either switch to the new behavior by using
the two upgrade steps or just keep the old behavior.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
apter). Use these adapters directly
in getContent().
- rename '@@view.html' to '@@view', '@@properties.html' to
'@@properties' and so on. This allows to remove some method aliases.
Cheers,
Yuppie
___
Zope
Hi!
Charlie Clark wrote:
Am 13.05.2013, 10:06 Uhr, schrieb yuppie :
Types: File, Image
Action: object/view
old: url_expr="string:${object_url}/file_view"
old: url_expr="string:${object_url}/image_view"
new: url_expr="string:${object_url}/view"
I think t
g:${object_url}/link_edit_form"
old: url_expr="string:${object_url}/newsitem_edit_form"
new: url_expr="string:${object_url}/edit"
'object/edit' specifies the Action: 'edit' Action in category 'object'
url_expr="string:${object_url}/
make migration easier.
Cheers,
Yuppie
Types: Discussion Item, Document, Favorite, Link, News Item
Action: object/view
old: url_expr="string:${object_url}/discussionitem_view"
old: url_expr="string:${object_url}/document_view"
old: url_expr="string:${ob
hosting service. They did it because of
the proprietary features GitHub is building around the repositories. I
don't want to give the responsibility for the way I collaborate with
other contributers into the hands of a company.
Cheers,
Yuppie
___
Hi!
Martin Aspeli wrote:
On 2 March 2013 16:18, yuppie
mailto:y.2013-E2EsyBC0hj3+aS/vkh9...@public.gmane.org>> wrote:
Yes. I have objections.
I'd like to keep contributing to CMF. But I'm not going to support
GitHub Inc. by using its services
Seriously?
Yes.
F packages?
Yes. I have objections.
I'd like to keep contributing to CMF. But I'm not going to support
GitHub Inc. by using its services.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/li
ither.
isConstructionAllowed just returns a boolean value, _verifyObjectPaste
tells you what went wrong. Maybe there should be a new method that
raises errors and can be used by isConstructionAllowed and
_verifyObjectPaste?
Cheers,
Yuppie
___
Zope-trunk Python-2.7.3 : Linux
https://mail.zope.org/pipermail/cmf-tests/2012-September/016705.html
All the failures are caused by Zope changes, see this thread:
https://mail.zope.org/pipermail/zope-dev/2012-September/044791.html
Cheers, Yuppie
Hi Charlie!
Charlie Clark wrote:
Am 07.09.2012, 09:01 Uhr, schrieb yuppie :
And I have a quick and dirty view implementation for local
role/sharing. Reimplementing it based on formlib would be a lot of
work, so maybe I should just check in my code.
As I'm not even sure what it doe
Hi Charlie!
Charlie Clark wrote:
Am 07.09.2012, 09:01 Uhr, schrieb yuppie :
[-] means that we don't want/need to convert this
[?] means that we still have to decide if and how this should be
converted
[/] means unfinished
Regarding RSS: you've written
[/] ISyndicatable @@rs
Hi Charlie!
Charlie Clark wrote:
Am 06.09.2012, 16:24 Uhr, schrieb yuppie :
There are the (incomplete) todo lists for browser views. I'd also
like to revisit the names we did choose for the views and make them
the default target of Actions.
hm, I drew up the lists from the existing Sc
Hi Charlie!
Charlie Clark wrote:
Am 06.09.2012, 13:11 Uhr, schrieb yuppie :
What is, in your view, missing from a final release?
Laurence proposed some changes for the utilities:
https://mail.zope.org/pipermail/zope-cmf/2012-September/030381.html
If we agree that's the way to go
Hi Charlie!
Charlie Clark wrote:
Am 05.09.2012, 09:07 Uhr, schrieb yuppie :
The setup of your doctest looks fine, you just have to enable
syndication for the folder (app.site) to get the view.
Tests landed yesterday and I also ran them with the oldstyle
implementation.
Good.
What is
warnings, maybe even a switch for disabling the legacy
behavior.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
l prevent upgrades.
Not sure who is missing something and what. Just a wild guess:
Are you aware of the fact that five.localsitemanager just removes the
RequestContainer, not the complete acquisition chain?
And that CMF 2.3 adds a RequestContainer in getPortalObject()?
Cheers, Yuppie
_
tion chain. So if this has to be fixed inside the tools,
getUtility(ISiteRoot) is sufficient.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cm
Hi!
Laurence Rowe wrote:
On 5 September 2012 13:26, yuppie
wrote:
I don't think relying on getSite() is a good idea. As you mention it doesn't
always return the portal object. And the fact it is stored with the request
in its context is just an accidental side effect. What wo
Hi!
Charlie Clark wrote:
Am 05.09.2012, 11:48 Uhr, schrieb yuppie :
getToolByName is no option because it is part of the machinery that
should become obsolete.
Not sure that is should actually ever become obsolete. Much as I am in
favour of the interface-based lookup, these tools are an
Hi Laurence!
Laurence Rowe wrote:
On 5 September 2012 11:48, yuppie
wrote:
2.) Site root lookup: =
In several tools we still assume aq_parent(aq_inner(self)) is the
portal. Or other code uses the tool as context object, expecting root
and request in its acquisition
n the site root.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
me and
DateTime with it's convenient rfc822 method
Removing DateTime completely has no high priority. If you need it as a
formatting tool, just use it.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailm
ce that by
queryUtility(ISkinsTool) without providing any backward compatibility
code for getSkinsFolderName.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpa
behavior.
Cheers, Yuppie
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
dependencies.
Maybe this could/should be declared in an extra if you want to be explicit?
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Hi Ross!
Ross Patterson wrote:
On Fri, Apr 27, 2012 at 2:58 AM, yuppie wrote:
Ross Patterson wrote:
Log message for revision 125311:
Add GenericSetup export/import support for type information action
descriptions.
Two questions:
- Why didn't you merge this into trunk?
Be
Hi Ross!
Ross Patterson wrote:
Log message for revision 125311:
Add GenericSetup export/import support for type information action
descriptions.
Two questions:
- Why didn't you merge this into trunk?
- Why didn't you add ZMI support for descriptions?
Cheers,
OS,
Debian and FreeBSD.
Today I saw these errors in one of my buildouts. I was able to fix them
by improving the tear down in MembershipToolTests.
Can you confirm this is fixed?
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@zope
t_utils.py
2012-04-09 16:30:40 UTC (rev 125119)
@@ -27,7 +27,7 @@
MULTIPARAGRAPH_DESCRIPTION = \
'''Description: this description spans multiple lines.
-
+
It includes a second paragraph'''
I can't reproduce the other failures.
Cheers, Yuppie
_
Hi!
Jens Vagelpohl wrote:
On Apr 9, 2012, at 23:10 , Charlie Clark wrote:
Am 22.03.2012, 13:28 Uhr, schrieb
yuppie:
The tools are *local* utilities. Including the ZCML doesn't fix this issue. You
have to run the upgrade step.
Should we add a warning to CMFTools.utils.getToolByNam
Hi!
Charlie Clark wrote:
I finally landed my update step for syndication during the PyCon
sprints! I thought I had a few more browser views to update to using the
EditSettingsForm but on a quick check of the files it seems that this
has already been done. Yuppie, I remember that you have
ate optional package they should be fixed instead of giving up.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
# BBB: fallback for CMF 2.2 instances
utool = aq_get(self, 'portal_url')
If you can't run the upgrades from the ZMI it might be necessary to add
more fallbacks in CMF.
HTH,
Yuppie
___
Zope-CMF maillist -
Hi!
Charlie Clark wrote:
> * apparently the "absolut" skin can cause problems with used in
> combination with profiles. Yuppie, do you have any more information on
> this?
Not sure what you mean. I had some problems getting rid of oldstyle
skins completely (including main_
Charlie Clark wrote:
> Am 04.10.2011, 10:55 Uhr, schrieb yuppie:
>>> Regarding zope.annotation - IAttributeAnnotatable creates a new object
>>> within the folder
>> Why do you think so? AFAICS the default implementation stores all
>> annotations in the __annotati
Hi Charlie!
Charlie Clark wrote:
> Am 30.09.2011, 10:55 Uhr, schrieb yuppie:
>
>>
>> AFAICS only the getUpdateBase method of ISyndicationTool needs to be
>> backwards compatible. Everything else is new API or doesn't return
>> DateTime objects. Wouldn't
backwards compatible. Everything else is new API or doesn't return
DateTime objects. Wouldn't it be better to use datetime internally? You
already need an upgrade step for SyndicationInformation. Writing an
additional upgrade step for SyndicationTool wouldn't be much extra work.
e reason but that's okay.
zope.formlib expects that setUpWidgets is always called before
handle_change. If you test handle_change isolated, you have to set
adapters by hand.
Cheers, Yuppie
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail
Hi Charlie!
Charlie Clark wrote:
> Am 27.01.2011, 17:05 Uhr, schrieb yuppie:
>
>> zope.formlib is not made for DateTime values and encoded strings. So you
>> *always* have to make sure these values are converted correctly. And it
>> is hard to do that inside the form code
ully someone
> will put the effort in to port Plone to CMF 2.3 in time for Plone 5.
Who ever that is: The upgrade steps for CMFDefault might give some hints
what needs to be upgraded. And you are always welcome to ask questions
on this list if you have trouble with upgrading.
Hi!
Hanno Schlichting wrote:
> On Wed, Sep 21, 2011 at 1:57 PM,
> yuppie wrote:
>> I plan to use zope.globalrequest as fallback if self.REQUEST is not
>> available.
>>
>> What's the best approach for the five.globalrequest dependency? Just use
>>
Hi!
Hanno Schlichting wrote:
> On Tue, Sep 20, 2011 at 12:19 PM,
> yuppie wrote:
>> But an additional ZCatalog branch is an additional maintenance burden.
>> And the required change is small and 100% backwards compatible. The
>> zope.globalrequest dependency could be ma
Hi Hanno!
Hanno Schlichting wrote:
> On Mon, Sep 19, 2011 at 3:56 PM,
> yuppie wrote:
>> But with zope.globalrequest we can avoid modifying the API. So if it is
>> fine to smuggle a zope.globalrequest dependency in Zope 2.13, that might
>> be the better solution
Hi!
Hanno Schlichting wrote:
> On Mon, Sep 19, 2011 at 11:57 AM,
> yuppie wrote:
>> Currently CMF trunk contains some hacks to work around the catalog brain
>> issues. But I hope there is a better solution. Maybe the ICatalogBrain
>> methods getURL, _unrestrictedGetObj
have a
REQUEST argument that is used instead of self.REQUEST?
Any kind of feedback and help is welcome.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net
Hi!
Jens Vagelpohl wrote:
> On Sep 12, 2011, at 11:52 , yuppie wrote:
>> I propose to use 'five.globalrequest' instead of self.REQUEST inside
>> tools. AFAICS that allows to convert *all* tools into utilities.
>
> Why would you want to add a dependency for 3
view code. But that never happened. So these
tools and all tools depending on these tools are still not converted.
I propose to use 'five.globalrequest' instead of self.REQUEST inside
tools. AFAICS that allows to convert *all* tools into utilities.
What do you think?
Cheers,
is beyond my feeble powers. It looks like all the doctests are
> failing.
>
> Charlie
Zope trunk is broken, it has similar failures and errors:
https://mail.zope.org/pipermail/zope-tests/2011-August/048589.html
Yuppie
___
Zope-CMF maillist -
es. I don't think it's worth the
trouble to do it differently in just one place:
- Plone uses string for 'fullname'
- If we add a 'fullname' Python property to IMemberData, it can still
return the decoded value. In CMF 2.3 IMemberData objects are just
adap
E.g. member.getProperty('email') would always work. You don't have to
use member.getProperty('email', '') and in a next step attribute access
(member.email) could be implemented reliable.
Cheers,
Yuppie
__
instead of member id *if* fullname is not empty
- make the related MemberDataTool properties undeletable (only the 6
basic ones - of course you can still change and delete all property
values and you can add or remove other properties)
Any objections?
Cheers,
Yuppie
__
still have some trouble using mr.developer in Eclipse. But if it works
for everybody else and the nightly tests don't break I'm fine with
replacing the svn:externals.
Cheers, Yuppie
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.o
except KeyError:
> -pass
> +pass
>
> -_import_step_regs = []
> -
> def cleanUpExportSteps():
> -global _export_step_regs
> -for name in _export_step_regs:
> -try:
> -_export_step_registry.unregisterStep(name)
> -
Hi!
Charlie Clark wrote:
> Am 22.02.2011, 11:46 Uhr, schrieb yuppie:
>> 2.) direct MemberData property access
>> -
>> Wrapped users are now MemberAdapter objects. So wrapped users no longer
>> have attributes like 'email&
Hi!
yuppie wrote:
> I propose to split this up into a persistent MemberData object that is
> just used for storing member data and a new non-persistent MemberAdapter
> that provides all the methods currently provided by MemberData objects.
Done: http://svn.zope.org/?rev=120512&vie
.10 Python-2.4.6 : Linux
This buildout was moved to CMF/branches/2.1-zope210.
> Subject: OK : CMF-2.1 Zope-2.11 Python-2.4.6 : Linux
This buildout was moved to CMF/branches/2.1-zope211.
Please make sure you use the new locations before I delete the old ones
hat on the
trunk. IUser is only available in Zope 2.13.2+, so I'll have to make
that Zope version required for CMF trunk.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope
please let me know.
Cheers, Yuppie
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
yuppie wrote:
> yuppie wrote:
> DebugModeTests have been disabled by default. Now I see 3 errors on
> FAT32 and one error on NTFS:
>
> Error in test test_DeleteAddEditMethod
> (Products.CMFCore.tests.test_DirectoryView.DebugModeTests)
> Traceback (most recent call last):
>
yuppie wrote:
> AFAIK this is primarily a file system issue, not an operating system
> issue. 'Last modified' time is updated on NTFS, but not on FAT32.
>
> Not sure what we need to support: I guess everybody is working with
> Windows versions that support NTFS, but maybe
Last modified' time is updated on NTFS, but not on FAT32.
Not sure what we need to support: I guess everybody is working with
Windows versions that support NTFS, but maybe some people still develop
on FAT32 partitions.
Maybe there is an easy way to detect the file system?
Cheers,
Yuppie
Hi Charlie!
Charlie Clark wrote:
> Am 26.01.2011, 16:50 Uhr, schrieb yuppie:
>
>> I'm not happy with the current state of CMF trunk. Especially the
>> syndication related changes cause trouble in different ways:
>> - SyndicationInformation was replaced by Syndica
some small issues.
But the bigger issues still exist. Based on what I encountered I wrote
this small guide: http://svn.zope.org/*checkout*/CMF/trunk/CODINGSTYLE.txt
Please keep the the trunk stable and use your own branch for unfinished
changes.
Cheers,
Y
to
> relate the permissions and the portal_types.
>
> Is this correct ?
I'm afraid you can use five:registerClass only once per class. The
directive modifies the class. meta_type to class is a 1:1 relationship.
Cheers, Yuppie
___
Zope-CMF maillist
ests
> commit
That only works if someone makes sure bootstrap.py and buildout.cfg are
up to date. You just did have to update buildout.cfg on CMFCore trunk.
Cheers, Yuppie
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/
and buildout files on each branch of each
Product? Who is using and maintaining them?
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for
r
I updated the testrunner version. This no longer works:
/usr/local/python2.6/bin/python ./bin/test
Should now be:
/usr/local/python2.6/bin/python -S ./bin/test
or just:
./bin/test
Cheers, Yuppie
___
Zope-CMF maillist - Zope-CMF@
Charlie Clark wrote:
> Am 08.12.2010, 14:48 Uhr, schrieb yuppie:
>
>> In line 59 you just have a bare CMFSite object without any tools.
>
> Hi Yuppie,
>
> thanks for the quick reply. How come I don't have any tools? Is this
> related to more recent buildouts
ite
In line 59 you just have a bare CMFSite object without any tools.
HTH, Yuppie
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
ipts. 'zopepy' was fixed,
'i18n-cmfdefault' not.
But now everything should work again.
Ciao, Yuppie
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
t;OLD_" as prefix. AFAICS about
20% of their content is still useful, so I did not delete them. But it
would be nice if someone would clean them up.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/li
o be in as soon
> as possible, I'm planning to get some more stuff over the next few days.
> Can we wait until next Wednesday (bug day?)
Are you sure you want to make these changes in CMF 2.1? Jens is not
talking about CMF 2.2 or trunk.
Cheers,
Yuppie
out". If they have no clue, the
".buildout" will make no difference for them.
"CMF.buildout" sounds like it would be "the official sanctioned buildout
for the CMF". How should they know it is a developer convenience?
Cheers,
Yuppie
Hi!
Jens Vagelpohl wrote:
> On 8/5/10 16:52 , yuppie wrote:
>> Charlie Clark wrote:
>>> I'm actively abstaining as while I understand the need to clean things up,
>>> I'm not sure I understand the whole context (my lack of understanding
>>> rather
1 - 100 of 158 matches
Mail list logo
