I'm using plone 4.2 and want to use product CMFBibliographyAT. After running command buildout I get a lot of error messages regarding "'return' outside function". When the command exits it prints:
*************** PICKED VERSIONS ****************
[versions]
Products.ATExtensions = 1.0
Products.CMFBibliographyAT = 1.1.2
bibliograph.core = 1.0.3
bibliograph.parsing = 1.0.1
bibliograph.rendering = 1.0.2
psycopg2 = 2.4.5
pyisbn = 0.6.0
*************** /PICKED VERSIONS ***************
When I go to zope interface and I can see these archetypes:
CMFBibliographyAT::LargeBibliographyFolder Uninstall
CMFBibliographyAT::DuplicatesBibliographyFolder Uninstall
CMFBibliographyAT::BibliographyFolder Uninstall
However, in plone when I try to add some content, there is no bibliography.
Any ideas why I can use this product?
Pedro
You did not actually get an error, your buildout completed fine.
When installing eggs, any .py files are compiled to .pyc cached byte-code files. However, Python Script files in Plone skin layers are a special form of Python that are treated as functions, and byte-compiling these always fails. This is a side-effect and can be ignored, see Buildout and Syntax Errors.
The unified installer buildout configuration has been set up to inform you if buildout had to pick versions for you if not explicitly pinned to one.
The output you see tells you exactly what versions it picked, and you can re-use that output to set the pins yourself. Find the file versions.cfg and add the lines below the [versions] block in that file, below the same [versions] section you'll find in that file.
For more information on such version pinning and other buildout issues, see:
Brief version pinning tutorial
Buildout troubleshooting manual
The Unified Installer manual
If you do run into problems with these packages and get errors when you run your Zope instance, errors will be logged either to the console (when run in foreground mode) or the errors log. See Add on product installation fails for help with troubleshooting these.
Related
I am building the Visual Studio Code from the source checked out from the git repository:
git clone https://github.com/microsoft/vscode
I am building using:
export NODE_OPTIONS=--max_old_space_size=2048
./scripts/npm.sh install --arch=armhf
./scripts/code.sh
I am using node 10.16.3 on a Raspberry PI 4, using Raspbian buster
There were no errors during build.
The installation downloads a precompiled version of electron on the first run.
However each time I try and run code, it starts but with an error:
[storage state.vscdb] open(): Unable to open DB due to Error: Cannot find module '../build/Release/sqlite
If I look in node_modules/vscode-sqlite3/build/Release/
I can see:
sqlite3.a
sqlite.a
It is unclear to me why electron/vscode cannot find this library. I would be greatful for any pointers on how to tell the runtime where to look for the modules.
On inspecting the build scripts and after many painful experiments, I've found and solved the 2 problems leading to this error.
The fact that .a static libraries are left behind hinted that some settings in the binding.gyp, config.gpy and/or makefiles are wrong, as Native Node Modules are normally dynamic libraries with an .node extension. One conditional line in the binding.gyp file under vscode-sqlite3 seems to the the culprit:
...
["target_arch=='arm'", {"type": "static_library"}]
...
Disable that line (by removing it or changing 'arm' to something else) and then run:
node-gyp configure
to regenerate the config.gpy file(s) under the build directory. Then build the module with:
node-gyp build
A sqlite.node will be generated in build/Release.
Unfortunately, the latest electron ABI version rarely matches that of the Node.js version. In my configuration, the electron ABI version is 72 (v6.0.12) but the latest stable Node version is for ABI 64. Therefore we have to do an electron-rebuild to update the sqlite.node to match the electron version.
To do this, you would have to first install electron-rebuild (yarn add electron-rebuild) then run electron-rebuild by giving supplying explicitly the version number of the electron binary that vscode downloaded:
electron-rebuild -v 6.0.12 -m /home/dev/vscode -o vscode-sqlite3
Of course you would have to state the version number of your particular version of electron you are building for.
(Please look up electron-rebuild --help for the meaning of the options. It takes a while to rebuild the binary module...)
The resulting sqlite.node can then be moved into the build/Release/. directory under the vscode project directory. Voila, we have a working latest version VS-Code for Raspbian!
In pre-buildout-times one would install ZOPE2 by downloading the tarball of http://old.zope.org/Products/Zope/ and do the configure/make/install-procedure.
Since ZOPE version 2.12 releases are made on pypi. Would it still be possible to install newer ZOPE2-versions the same way manually without using buildout?
Perspectively Plone is ment to be put on top ZOPE2, but to narrow down the question for now, an answer only concerning ZOPE2 is very welcome.
I may be late to the party but:
As a starting point: There is the projects installation docs at https://zope.readthedocs.io/en/2.13/INSTALL-virtualenv.html which worked fine (and is without buildout) the last time I tried.
Since I use virtualenv and pip a lot, the above method becomes cumbersome fast (installation from different path than pypi and local equivalent, accidentally upgrading wrong packages when installing more packages) I made an almost pure reference installation and then just did a pip freeze > zope_2.13_requirements.txt.
Now I can just create a new virtualenv and do a quick pip install -r zope_2.13_requirements.txt, can do it directly via pipy and have a fresh installation whenever I need.
The main part of the question probably is that you probably want to use Zope 3 and not legacy Zope 2 (which e.g. Plone still depends on). Zope is not a signle, coherent, entity. What components of Zope stack you want to use (zope.interface, zope.component, ZODB, Medusa web server, Zope management interface, others?) All are individual Python packages and can be used as is in any Python application with normal Python package workflow.
Buildout is nothing but scripts, templates and Python package installer with advanced dependency solving.
You can still install all Zope packages by hand, resulting a lenghty requirements.txt. Zope 2 comes with command line scripts for creating and maintaining databases and you can call these scripts by hand, no need to go through buildout. You can also create configuration files by hand, e.g. looking the examples generated by buildout if you have some specific legacy project in mind.
For example, substanced, a CMS based on Pyramid and ZODB, does not rely on buildout. Pyramid internally uses zope.interface, zope.component and various other packakages.
I am having a sudden issue with installing Plone 4.2.4. I have pinned PloneFormGen to 1.7.11 but the buildout fails with the following error:
The version, 1.4.4, is not consistent with the requirement, 'plone.app.jquery>1.6'.
While:
Installing client1.
Error: Bad version 1.4.4
If I remove PFG from the buildout, it runs fine. I have pinned plone.app.jquery to 1.7.2 (even though it states its not compatible with < Plone 4.3) and the buildout runs successfully, but afterwards, if I update PloneFormGen from 1.7.6 to 1.7.11, it breaks the site.
The buildout is a standard Unified Installer build of Plone 4.2.4, using the out of the box version.cfg. I have extended this with my own config to add other components.
This build recipe I created months ago and it has worked flawlessly on other systems, but my most recent use of this recipe gives me the failures.
Any ideas would be greatly appreciated.
UPDATE:
I found an email on the Plone Users group by someone who was having a very similar issue to this. The fix seems to be to pin plone.app.jquery to 1.7.2 as well as pinning collective.js.jqueryui to 1.9.2.0. I did this and the issues I was experiencing appear to be resolved. However, I'm not comfortable with this solution as it appears to be an underlying issue with these two packages.
As you mentioned in your question update, you need to additionally pin plone.app.jquery to a newer version.
This is a fine solution and, if anything, PloneFormGen is just lacking in documentation so people are aware of it.
Please consider contributing to the README to help provide better instructions to install on the version of plone you're using: https://github.com/collective/Products.PloneFormGen/blob/master/Products/PloneFormGen/README.txt
I'm having some difficulty upgrading my Plone install to 4.2.5.
The old Plone/zope install was running on Ubuntu 8.04. I upgraded the OS to 12.04, and reinstalled plone and zope.
I followed the instructions at: http://plone.org/documentation/manual/upgrade-guide/minor-version-upgrades for the upgrade.
The 12.04 install was successful, the trouble comes when I copy my old configs, and data over into the new install.
When I run bin/buildout after copying over, I get the message:
Error: Buildout now includes 'buildout-versions' (and part of the older 'buildout.dumppickedversions').
Remove the extension from your configuration and look at the 'show-picked-versions' option in buildout's documentation.
I tried removing the extensions, which allows bin/buildout to finish without error, however when I start zope, I get the following error:
File "/home/plone/Plone/buildout-cache/eggs/ZODB3-3.10.5-py2.7-linux-x86_64.egg/persistent/init.py", line 19, in
from cPersistence import Persistent, GHOST, UPTODATE, CHANGED, STICKY
ImportError: /home/plone/Plone/buildout-cache/eggs/ZODB3-3.10.5-py2.7-linux-x86_64.egg/persistent/cPersistence.so: undefined symbol: PyUnicodeUCS2_AsEncodedString
Python comes in two Unicode flavours; narrow and wide, or UCS2 and UCS4, with wide builds allowing for more Unicode character support. Your compiled C extension is compiled with a wide Python but you are now using a narrow Python.
Your best bet is to remove the ZODB3 egg and have buildout recreate it. Delete the /home/plone/Plone/buildout-cache/eggs/ZODB3-3.10.5-py2.7-linux-x86_64.egg directory altogether.
You probably have to do this for more eggs that have extensions.
The error
When I run pip install PySide – whether in a virtual environment or not – build fails with the following error:
... [lots of build info, including a few warnings but no errors, for shiboken]
Linking CXX executable shiboken
ld: framework not found QtCore
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Seeing as I have QtCore installed and the framework present (see below), I'm not sure why that should be.
Setup info
Software versions
OS X 10.8.2
Qt 4.8.4 from the developer distributed binaries
Python 3.3 installed and working normally
XCode 4.6
Apple LLVM version 4.2 (clang-425.0.24) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin12.2.1
Virtual environment generating using pyvenv (with and without --no-site-packages)
Other configurations attempted
Python 2.7 installed and working normally
Virtual environment generated using mkvirtualenv (with and without --no-site-packages)
virtualenv 1.8.4
mkvirtualenv 3.6
System configuration
I've confirmed that QtCore is in fact installed correctly: ls /Library/Frameworks shows a number of Frameworks, including QtCore.Framework.
My path currently includes both /Library/Frameworks/QtCore.framework and /Library/Frameworks/QtCore.Framework/Versions/4 – the former of which has a symbolic link to the component in the latter location. I've even tried it with /Library/Frameworks, though for obvious reasons I didn't expect that to help and it did not.
Other notes
I've tried the same thing with easy_install and by doing a pull from the Git repository and building manually using setup.py. As one would expect, they all return the same results.
Things I've already read
PyPi Installation walkthrough
Link error: QtCore.framework/Versions/4/QtCore for architecture x86_64 (Stack Overflow) – but it seems the linker is already asking for the framework, based on the error message I'm receiving.
Mac OS X: trying to link (ld) against a framework (Stack Overflow) – general info on linking against Frameworks; again, I seem to have this covered.
OSX deployment target confusion for 2.8.10 (CMake Mailing list) – looks like a very similar error, but I don't have direct control of the -isysroot flag using pip (or easy_install or even python setup.py) for one and for another, installation structure seems to have changed substantially between OS X 10.6 and 10.8. For example, /Developer no longer has the SDKs directory in it at all.
CMake bug report 0013765 – this one looks exactly the same, but appears to have been patched, so I'm not sure why it would still be causing me a problem.
Preferences
I'm not using a package manager like Homebrew or MacPorts at this time, and I'd prefer not to, either, as I need to get as close as possible to a platform-agnostic installation procedure for this (we're looking at doing cross-platform development; I'll ultimately be targeting Windows applications primarily, but need to see if it's workable on my Mac development machine outside a VM).
It needs to be able to work with a Python 3-style virtual environment (pyvenv) setup, as that's our preferred means of isolating our particular requirements.