Very new to setting up Plone 4 and trying to integrate Solgema.fullcalendar but when running buildout I get an error saying it needs zope.schema 3.6.0 and I have 3.5.4. I cannot for the life of me work out how to update it. I assume I am missing something fundamental here but it is doing my head in as I imagine as I will encounter this kind of issue again and again as I progress.
" Installing instance.
Error: There is a version conflict.
We already have: zope.schema 3.5.4
but z3c.form 2.4.2 requires 'zope.schema>=3.6.0'."
Looked around and noticed that putting zope.schema>=3.6.0 in eggs might work but that didn't actually trigger an update just caused a bad install error.
If anyone has any ideas or needs something more to go on please let me know!
Thanks
Chris
If you want to use z3c.form inside Plone, best update to Plone 4.1 which is currently available as a release candidate. 4.1 comes with z3c.form in it and has the newer zope.schema version.
In the general case you will need to have a versions section in your buildout configuration in which you can specify exact version requirements for all distributions you want.
[buildout]
extends = ...
versions = versions
[versions]
zope.schema = 3.6.0
Inside the setup.py files you should never specify exact version requirements. Only put minimum requirements into these if your specific library absolutely requires a new feature from another library.
See Hanno's answer. I will add that I cannot think of a good reason anymore to use '>=' (or '<=' or '==') to specify minimum, maximum or exact versions anywhere in a buildout config. Version specifications should only be in a [versions] section. It has been a while since I last used a buildout config that used the comparison operators, but I remember it could lead to problems, especially when upgrading; the only way out would at times be to remove the '.installed.cfg' file to make bin/buildout run in a fresh state.
(Note that '>=' in a setup.py is perfectly fine.)
Related
I would like to use the exactly same version of flake8 in requirements.txt and in .pre-commit-config.yaml.
To avoid redundancy I would like to keep the version number of flake8 exactly once in my repo.
Can pre-commit.com read the version number of flake8 from requirements.txt?
it cannot
pre-commit intentionally does not read from the repository under test as this makes caching intractable
you can read more in this issue and the many duplicate issues linked there
for me, I no longer include flake8, etc. in my requirements files as pre-commit replaces the need to install linters / code formatters elsewhere
disclaimer: I created pre-commit
I'm trying to require the bundle in my Symfony project: FOSUserBundle. But it doesn't work, apparently I have to increase the memory_limit. But I can't make it work.
I've already tried to look for the php.ini file to change the memory_limit. But there is no php.ini file in my Symfony project. Why is it not there? Have I forgotten to install something? And if I want to add it manually, where can I put it? There are PHP.INI files in the MAMP folder. I've tried to change the memory_limit value, doesn't help.
And I've tried to run this in the terminal after navigating to the right project folder: php -d memory_limit=2G composer update.
The reaction I get is more or less this:
Nothing to install or update
Generating autoload files
Incenteev\ParameterHandler\ScriptHandler::buildParameters
Updating the "app/config/parameters.yml" file
Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::buildBootstrap
Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::clearCache
Here is the error I get after trying to require the bundle:
Fatal error: Allowed memory size of 1610612736 bytes exhausted (tried to allocate 4096 bytes) in...
As you might see, I'm new to Symfony and Composer. Can you please help me out?
Thanks in advance!
There are a few things which will help a lot.
Ensure you are running the latest version of Composer.
Ensure you are running at least a recent version of PHP - version 7 improved the memory use substantially - sometimes halving the amount of memory used. Versions 7.2 or (better) 7.3 should be the versions being used now (summer 2019).
Actively limit the number of different versions of packages that Composer must check to see what could be valid to use.
Roave/SecurityAdvisories is a good start. This will also stop you installing versions of packages that have known security issues. It will also limit the search-space for valid packages, allowing Composer to ignore large swathes of possible packages, meaning that it does not need to hold large amounts of data for the various potential combinations.
You can add other versions of packages to further narrow the search-space. For example, you may have a number of wildcard "*" versions (also known as 'The Death Star Version Constraint') - which are almost always a bad idea. Mostly, a version number of the form "^3.4" or "^4.3" would be better - allowing upgrades from bug-fix versions and features (the 3rd and 2nd numbers), but not major versions, which can often contain breaking changes.
I solved it by setting the composer_memory_limit in the composer.json file under the 'config' part:
"COMPOSER_MEMORY_LIMIT": "2G"
On its website OpenFlipper says it can be compiled in three steps as:
cd build
cmake ..
make # or, even better, make -j8
However I get an error saying Qt is unable to be found at the cmake step and that I should specify a QT5_INSTALL_PATH. However even if I do this OpenFlipper is still issuing the same complaint!
You are not supposed to specify where Qt is installed in the QT5_INSTALLED_DIR but prior to that as environment variable in your terminal:
# assuming Qt was installed in your home directory, as is default
export CMAKE_PREFIX_PATH=~/Qt5.7.0/5.7/gcc_64/
# note that you now have to call cmake etc from that process
Compiling and running it after that you might get errors telling you GL_ARB_vertex_buffer_object is not present, even if your glxinfo | grep ARB_vertex_buffer is telling you it is.* Clicking "Ignore" results in a crash. To mitigate this, you have to manually change (4,3) to (3,0) in
OpenFlipper/widgets/coreWidget/CoreWidget.cc
If you still experience errors, try deleting your cmake cache, this is accomplished by using cmake-gui (was in the package cmake-qt-gui for me) and hitting "Delete Cache"
(optional) remove the very annoying warning message you get at every start of OpenFlipper by removing the line concerning "renderers shipped" in
OpenFlipper/Core/Core.cc
*: My teaching assistant told me that there is a bug in Qt (<5.9) that forces OpenFlipper to use the OpenGL Compatibility Profile. Additionally Intel and AMD drivers hand back an OpenGL 3.0 Core Context when asked for an OpenGL 4.3 Compatibility Context (my TA described this behavior as a "bug", I'm not so sure about this), leading to a crash in Qt. So this should be resolved in Qt 5.9 (not out yet). This seems to affect also mainly integrated graphics, so one could try using a dedicated GPU.
I have installed meld 3.14.2, at last (on NFS share in Redhat 6.3 server), after nearly 40 hours of efforts , installing each and every dependency and at last seems to be successful. But one finale error needs to be solved:
(meld:20703): GLib-GIO-ERROR **: No GSettings schemas are installed on the system
Trace/breakpoint trap (core dumped)
There was answer here: GLib-GIO-ERROR**: No GSettings schemas are installed on the system
I am not aware of these jargons before. So, please explain in detail what to do.
Do I need to set the variable $XDG_DATA_DIR or not? And if, why and what should be the value?
And I can find that the compiled file is already located in MyApp/share/glib-2.0/schemas.
However, I have also tried the following, even though the compiled schema is already there:
glib-complile-schemas <PATH_TO_SCHEMAS> --targetdir=MyApp/share/glib-2.0/schemas
But still I am getting the error. I have tried the variable too by setting it to MyApp and MyApp/share/glib-2.0/schemas. That too doesn't work.
I have also tried reinstalling gsettings-desktop-config. Still error. In my case, it's 3.12 version.
So, what's going on here?? Please explain. I have been sleepless. :(
Thanks you!
And also for your information, I have installed all the dependencies GTK+,ATK,CAIRO,PANGO etc... under the same installation directory with prefix=<base>/meld/deps.
Example:
meld binaries resides as follows: <base>/meld/bin/
cairo binaries are installed as follows: <base>/meld/deps/bin/
atk binaries are installed as follows: <base>/meld/deps/bin/
Similarly, you can think of other dependencies
Well I am unsure why you are installing it to its own prefix... but just setting GSETTINGS_SCHEMA_DIR to the full path to the schema dir should work.
I have developed a cookbook for my application which depends on Nginx cookbook. I have downloaded the Nginx cookbook from the following location
https://github.com/miketheman/nginx
and tried including the default recipe in my cookbook and overriding version attribute specified in the default attribute file. But irrespective of what i do, Nginx version 1.0.x is installed. I could not track from where it is fetching the version information. Can anyone help resolving this issue?
Thanks
If you specify the nginx cookbook as a dependency in your own wrapper cookbook, you have to deal with the strict load order of attribute files. Since Chef 11, all dependency cookbooks are loaded first, before the cookbook which requires them. As the dependency cookbooks (including nginx) are loaded, the attribute files are loaded and evaluated in this order:
attributes/default.rb of nginx
all other attributes files of nginx in alphabetical order
attributes/default.rb of your cookbook
all other attributes files of your cookbook in alphabetical order
As you can see, all the attributes of the nginx cookbook are initialized before your own attribute files are loaded. Thus, any dependent attributes (i.e. ones which are initializes using values of other existing attributes) use the values defined in the nginx cookbook, not your own.
Now, as you can see node['nginx']['source']['version'] is initialized with node['nginx']['version'] and thus uses the default value. This value is not changed if you just change node['nginx']['version'] later in your cookbook.
But fear not, there is a remedy :) You can reload specific attribute files in order to re-set their attributes. Here, this is rather convenient if you want to overwrite the nginx version. This is what I do in the attributes/default.rb in my nginx wrapper cookbook:
override['nginx']['version'] = '1.6.0'
override['nginx']['source']['checksum'] = '943ad757a1c3e8b3df2d5c4ddacc508861922e36fa10ea6f8e3a348fc9abfc1a'
# Reload nginx::source attributes with our updated version
node.from_file(run_context.resolve_attribute('nginx', 'source'))
from attributes/default.rb the default version is set to '1.4.4'
The simplest way to find out what version you've set it to is look for the following attribute on the chef-server UI:
['nginx']['version']
hopefully this should be set to whatever you've set it to!
I think that the real issue here is that the ['nginx']['version'] does not behave as you might expect it to.
According to the README file ...
If you use the nginx::default or nginx::repo recipes, you will load the latest binary package from either your platform's repository, or from the "stable" repo that is provided by the Nginx maintainers. The version attribute is effectively ignored!!.
The version attribute is only honoured if you use the nginx::source recipe, where it determines the URL of the source archive that is fetched and built.
If you use the nginx::ohai recipe, it updates the version attribute according to the version of Nginx that is currently installed.
Clear yet? If not then:
nginx::default gives you a (typically) old version of Nginx
nginx::repo gives you a (typically) more recent stable version of Nginx
nginx::source is the only recipe that allows you to specify the version of Nginx that you want.
If that doesn't seem to explain what you are seeing ... you need to dive into the recipe source code. The recipe behaviour (e.g. selection of installation repositories) varies across the different platforms / families.