When you use for instance a virtualenv, PyCharm will automatically detect which packages are installed. But PyCharm also supports buildout.
As the
documentation
rightfully claims, PyCharm can automatically detect the use of
buildout and enables support for it automatically. However, it defaults
to using the path from the bin/buildout
script. This usually only
adds the setuptools and zc.buildout eggs, so it is of little use.
Assuming you are using the
djangorecipe buildout
recipe, there is also a bin/django
script available. And that
script includes the paths to all the packages you have specified in
your buildout.
To do this, go to the settings, search for “buildout” and point PyCharm to the right script.
Once you have done that, you can immediately see that code completion works, but CTRL+click also takes you to the declarations inside e.g. the Django package.
]]>You can use buildout to have repeatable installations. With ZopeSkel you can get a buildout configuration really easy, however. But this is for your team and not ready for production (hosting, load balancing, etc). You also want to be able to test everything with Jenkins.
To make it even easier to deploy more sites for e.g. large organisations they needed something more. Goals:
This became zopeskel.unis. Important building blocks that are used:
extends
+=
(Do not mix “+=
” and “=
” because the latter one clears previous stuff)<=
(it will copy the content before the interpretation)${:_buildout_section_name_}
(gives you the name of the current section)The buildout.cfg
file is almost empty, it just extends a profile. Some folders
to manage configuration (e.g. profiles/etc
, profiles/modules
). There
are four working profiles: development, standalone, preproduction,
production. They are working on a profile for Jenkins.
In profiles/etc
:
defines.cfg
: password for supervisor, IP addresses, ports, etc.base.cfg
: main buildout config shared by all profiles.project.cfg
: all eggs specific for a project that you don’t want
to add to an external profile.versions.cfg
: the versions pins (and downloads) buildout should use.In profiles/modules
are configurations for e.g. LDAP, GetPaid,
theming (Diazo), ploneIDE. Make your modules as small as possible:
just the eggs that need to be added to [project-settings]
and
version pins.
You can use zopeskel.unis as an example for your own setup.
]]>Distutils: builds and distributes a package, registers and uploads it to PyPI. The standard in the whole Python community. It’s not actively developed however and there are features missing.
Setuptools sits
on top of distutils. It corrects some of the problems with
distutils. There is a simple dependencies mechanism, namespaces
packages and other nice stuff. Tarek encourages us to create source
distributions (python setup.py sdist
) instead of eggs. Eggs can be
interesting for some use cases though, but in the Plone world, please
use source distributions. Another advantage of setuptools:if you
upload your package to PyPI, everyone can just run easy_install my_package
to get your software and install it.
Setuptools is the de facto standard in the Plone community. But it is also broken since it inherits from distutils. The future of packaging is unclear at the moment.
Problems with packaging:
Solutions:
Tarek expanded on these three solutions:
Instead of creating a full mirror of PyPI , you can use collective.eggproxy. When using this proxy, it will give you the requested package from its cache. If it isn’t in the cache, it will download it from PyPI, give it to you and store it in the cache for the next time. You can use it in your buildout by using the index option:
[buildout]
...
index=http://my.mirror:8888
To have your own private PyPI, use
PloneSoftwareCenter
(PSC). This allows you to create your own egg repository. However,
there is a problem. The ~/.pypirc
file holds username and password
for PyPI. But having your private PyPI will mess things up: you’ll
need several accounts to upload to both PyPI and your private
repository.
In Python 2.6 you have the register
and upload
commands. For
Python 2.5 and 2.4 you’ll need to use
collective.dist. This
package gives the mregister
and mupload
commands and you can now
store multiple accounts:
[distutils]
index-servers =
pypi
another
[pypi]
username:user
password:password
[another]
repository:http://another.pypi.server
username:user2
password:password2
To make your private PyPI really private you can put the packages in a password protected directory. To be able to use them in buildout, you can use lovely.buildouthttp to access them.
By using PSC on plone.org it’s easy to update the product pages on plone.org. But you get even more: there is a rating system available, which PyPI doesn’t have. When the new site is live, we will have a PyPI compatible products section! :)
Since Clayton Parker already had a talk about buildout this morning, Tarek just gave some reminders.
Instead of needing 5 hours to get up-and-running (download Zope, Plone, install the right products in the right version, etc.), you can start working within 5 minutes.
The main reason for creating zc.buildout wasn’t this efficiency issue however. In 2005 Zope was a big monolithic package. Now, Zope is eggified and there are over 100 packages. And since you don’t want to install all those packages manually, a solution was needed. Enter zc.buildout.
Another advantage is that zc.buildout creates an isolated environment. You don’t need to install all the Zope and Plone packages system wide. This also proves to be a problem: you’ve got packages all over the place. If something needs to be fixed on a production server for instance, you need to visit several locations.
Best practices for using zc.buildout:
.cfg
file per target (development, production, etc.).collective.releaser provides a paste script which will give you a default layout for the project.
Windows developers/deployments are harder in this context. By using a package created by Tarek you can easily install the necessary stuff under Windows.
Suggestion:
buildout.cfg
dev.cfg
(extends buildout.cfg
)prod.cfg
(extends buildout.cfg
)[At Zest we use another setup by the way.]
Once you are done developing, run buildout on the target platform (Windows, 64-bit Linux, whatever). Turn on the offline mode and create an archive of your buildout. Now you can use the archive and get your buildout without having to use the network.
Besides setting up the project,
collective.releaser also
provides help for releasing packages. You can add release-command
and
release-packages
variables in your .pypirc
to get it working.
collective.releaser does make a lot of assumptions (e.g. that subversion is
used). Releasing the project can also be accomplished with collective.releaser
via e.g. the project_release
command.