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.
Related
I have configured Julia portable or standalone according to the link:Julia portable or standalone
But I want to update to the latest version of Julia 1.5.1.
How to proceed?
Should I add all the packages again?
Is there a way to import it to the new version?
Julia does not support version upgrade. It perhaps might work for some packages but you are always risking to running into issues.
Hence you need to delete the .julia folder (or set a new JULIA_DEPOT_PATH location which is configured by system variable) and just reinstall all the packages.
However if you for some reason strongly want to reuse the .julia folder you can try:
https://discourse.julialang.org/t/a-proper-introduction-on-how-to-update-julia-somewhere-accessible/28166
I got stuck installing "git clone https://gitlab.com/guile-git/guile-git.git". In which directory is this supposed to be cloned and installed?
Dunno if you're still looking for an answer but it doesn't seem you need this installed to install guix; the read-me of the repository says that you can install it via guix. guix is an agnostic package manager that you can install on any Linux distribution alongside the default package manager and guix is the default package manager of the GuixSD operating system (https://www.gnu.org/software/guix/).
If you're on a distro which doesn't use guix, you may not want to install guix (I've yet to find reason enough to, yet); if you use a lot of GNU tools or Guile (some Guile packages are available through guix), you may want to.
Most repositories that don't have a binary for you to run follow the build process of configure, make, and [sudo ]make install.
I cloned the repository, myself, and find that this one does, as well.
Get a terminal (if you haven't been using one, yet) and cd into the directory you cloned the repository to and then cd into the guile-git directory (cd guile-git).
If we do ls -l, we'll see that the only executable file there is the bootstrap one; I've never seen one before but doing ./bootstrap generates the configure file and sets up the make process for us. So now back in familiar territory.
Given these are Guile files, we'll probably want to install this under the same prefix as where Guile is installed so run which guile. I believe, if you install it under Ubuntu (I'm running Linux Mint), it'll install to /usr/bin/ but, if you install it manually, it'll install to /usr/local/bin/.
The latter is where mine is and that's the default prefix that configure uses so I can just do ./configure; if you wanted to install it under /usr/, run /.configure --prefix=/usr/.
This'll verify that all of the necessary libraries and programs that guile-git needs are installed and properly setup. Heads up that configure balked at me over not having the Guile module bytestructures installed (https://github.com/TaylanUB/scheme-bytestructures) so you may need to do that.
I'm not going to run through everything to get it installed but, once you can run it without any errors, run make to build it within the directory.
If you want to install it permanently on your computer with the rest of your operating system able to detect it, run make install. Since you'll likely've specified a directory under /usr, you'll have to do sudo make install so that the make process can have permissions to install under /usr/local or /usr.
Sorry if I reiterated anything you already knew; 'just didn't want to assume you knew something and result in confusion.
Usually my QML files start with import QtQuick 2.4 and other imports. How can I know which is the latest version of the imported modules without having to guess by type and build?
You basically don't have to know. By importing a particular version, you merely declare that you don't need the additional functionality of any potentially newer version. That doesn't mean that you won't use a newer version if one is available - it simply means that your code will refuse to run if only an older version than the one you need is present.
So, you should only change the imported module version if you happen to use the functionality (members, classes, etc.) from a newer version. That's all. And you will know exactly what version you need, since you're using the functionality you read about in the documentation. The documentation will state what module version it applies to.
The documentation for a given Qt Quick module from the Qt that you're using will state this - no need for release notes.
The QML module version information can be found in a file called plugins.qmltypes.
These files use JSON to store information (as far as I am aware).
In these files Qt uses the "exports" specifier to export the name and version of a module.
Example:
exports: ["QtQuick/Accessible 2.0"]
The example shows the version of the QtQuick.Accessible module.
The plugins.qmltypes are stored in a directory of the same name as base level module.
In the case of the example this would be QtQuick.
Base level modules are grouped under a directory titled qml.
That is "usually" located in a directory called qtx (in some case Qt).
Where x is the installed major version of Qt (in my case it would be qt5).
That means the plugins.qmltypes has a path that looks something like this:
/qt5/qml/QtQuick/plugins.qmltypes
The reason im explaining this bottoms up cause the rest of the path is dependent on how you installed Qt:
Package manager (portage) amd64 install path:
/usr/lib64/qt5/qml/
pip PySide6 install path:
~/.local/lib/python3.9/site-packages/PySide6/Qt/qml/
pip PyQt6 install path:
~/.local/lib/python3.9/site-packages/PyQt6/Qt6/qml
~/.local/lib/python3.9/site-packages/PyQt6/Qt6/qml
Package manager (apt) aarch64 install path:
/usr/lib64/aarch64-{forgot this part}-/qt5/qml/
I figure the version out in bulk with:
grep -r "exports:.*\\]" <insert install/OS dependent path>/qml/* | less
This doesnt grab multiple exports that are spread over multiple lines thought.
Since QML comes in 2 major versions when in doubt you could import version 1.0 or 2.0.
I am new to Plone and I am having trouble understanding how to install addons. I have read the documentation provided on their site, but I am still a bit confused.
The addon that I am trying to install is http://plone.org/products/uwosh.timeslot.
In the documentation, I see them using a something like cmd.exe, but I am not really sure what it is. Is it the python.exe located in the python folder?
Also, I am not clear if the addon that I wish to install is in an "egg" form.
Could someone please provide me with a detailed process for installation?
Thank you.
http://plone.org/documentation/kb/installing-add-ons-quick-how-to
Find, then edit your buildout.cfg file per instructions above to add the uwosh.timeslot egg.
Re-run bin/buildout (or bin\buildout on windows) from the main plone directory on the command-line (do not run from the bin directory as your current working directory).
Answering your other questions:
Yes, packages listed on PyPI.python.org are "eggs" in the sense that you install them as eggs in buildout, not classic "Products".
cmd.exe is MS Windows command-line, assuming you are using Windows, not Unix.
This is only useful if you know where your Plone installation is located on disk -- you should.
I have an RPM package for my application and the path of the installation is /company/application/version.
I am finding this difficult as it is a unix platform and there is no registry concept.
I need few things to be clarified:
How can i check the previous installed version number?
Every time I install my different version application all gets installed (i.e 2.5 and 2.6 both are considered as 2 different softwares because of the installation directory structure.)
How can I stop the newer version when old is already installed?
Without seeing the spec file, this is just shooting in the dark, but I would guess you are probably missing the 'Version' tag in your spec file. See http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html. In general, Maximum RPM is a good resource.