Saravanan666/pypi-org huggingface dataset:
Package: collective.recipe.libsvm
Introduction============This recipe brings libsvm to your buildout=======Example=======>>> write('buildout.cfg',... """... [buildout]... parts = libsvm...... [libsvm]... recipe = collective.recipe.libsvm... """)If we run the buildout it returns::>>> print system(buildout)Installing libsvm.libsvm: Downloading ...libsvm: Unpacking tarballlibsvm: Compile svm...libsvm: Creating libsvm egg<BLANKLINE>>>> ls(sample_buildout, 'parts')d  libsvm>>> ls(sample_buildout, 'eggs')-  setuptools-0.6c9-py2.4.egg-  svm.egg-linkd  zc.buildout-1.1.1-py2.4.egg>>> print system(buildout)Updating libsvm.<BLANKLINE>Changelog=========0.1 - Unreleased----------------* Initial release0.2 - Unreleased----------------* Normalize python-headers-directory so we can use paths relative tothe python used by buildout like::python-headers-directory = /usr/local/python/2.4.5/bin/python/../../include/python2.40.3 - Unreleased----------------* Use canonical location of the libsvm distribution.
Package: collective.recipe.logger
IntroductionThis recipe creates the program daemon (logger) which is listening to the socket.
It generates logs in an appropriate format (JSON, CSV, PICKLE).Example usageThe simplest way to use this recipe is to add it to yourbuildout.cfglike this:[buildout]
parts = logger

[logger]
recipe = collective.recipe.loggerGo tocollective/recipe/logger/README.rstto see more details.DevelopmentCode repository:https://github.com/potar/collective.recipe.loggerThe code comes with abuildout.cfg.  Please bootstrap the
buildout and run the createdbin/testto see if the tests still
pass.  Please add tests if you add code.Questions and comments send to the Plone product-developers list or to
potar:poburynnyitaras@gmail.comSupported optionsThe recipe supports the following options (none of which are needed by default):ipIt’s a host ip. Default value: localhostportIt’s an application (daemon) port.
Default value: 8090 (DEFAULT_TCP_LOGGING_PORT)maxlenIt’s a circular buffer size.
Default value: 100. It means that you can store 100 records into storage.modeIt’s file mode bits which is intended to the file storage.
Default value: 0644formatIt’s a storage type.
Options: ‘csv’, ‘json’, ‘pickle’.
Default value: ‘json’eggsIt sets up additional products. They help serialize objects.
For example, your object will not be a standard python collection so you need an appropriate class for this object.
If you use Plone I recommend you set upeggs = ${instance:eggs}NotesA storage filename is generated by id_generator (src/collective/recipe/logger/utils.py).ContributorsTaras Poburynnyi (potar), AuthorChangelog0.1.0b1Initial release
Package: collective.recipe.maildump
collective.recipe.maildumpContentscollective.recipe.maildumpIntroductionInstallationHow to use itCHANGES0.2.2 (2016-01-10)0.2.1 (2016-01-09)0.2 (2015-07-12)IntroductionThis recipe installsmaildumpa
python-based clone of the awesomeMailCatchertool.InstallationLook at this example:[buildout]
parts = maildump

[maildump]
recipe = collective.recipe.maildumpThat’s all.How to use itJust runbin/maildumpctl. By default it will start the web server on port1080and the smtp server on port1025.Configure your application to use the SMTP server on localhost, port 25, no
user, and no password.For example, on django add the following to yousettings.pyfile:EMAIL_HOST = "localhost"
EMAIL_HOST_USER = ""
EMAIL_HOST_PASSWORD = ""
EMAIL_PORT = 1025
EMAIL_USE_TLS = False
DEFAULT_FROM_EMAIL='contacto@holokinesislibros.com'
SERVER_EMAIL = 'contacto@holokinesislibros.com'CHANGES0.2.2 (2016-01-10)Packaging issues0.2.1 (2016-01-09)Including missing files in release0.2 (2015-07-12)Initial release to PyPI.
Package: collective.recipe.minify
collective.recipe.minifyContentscollective.recipe.minifyDetailed DocumentationSupported optionsExample usageContributorsChange historyDownloadCode repository:http://svn.plone.org/svn/collective/collective.recipe.minifyDetailed DocumentationSupported optionsThe recipe supports the following options:css-commandThe script to be used for css minification. The YUI compressor is a good
choice here. This option is not required. If it is omitted, a very simple
whitespace stripping is done [’ ‘.join(RESOURCE.split())]. The command
must write its result to the standard output.js-commandSame ascss-commandbut used for JavaScript resources.ignoreA list of fnmatch-patters. If a filename matches one of these
expressions, it is omitted from the minifying process.pathsA list of paths, which contains JavaScript and CSS resources. All files
ending with ‘.js’ and ‘.css’ are considered, except those which are ignored
explicitly (see ignore option).suffixFilename suffix that is used for the copy of the original file. The default
is-full. If the orignal filename isstyle.cssthe minified version
will bestyle.cssand the original development version will bestyle-full.css.include-develInclude all packages listed in the devel-section of the buildout. This
option is turned OFF per default.verboseSet verbosity for minify runs. The allowed values aretrueandfalseand the default isfalse.Example usageA simple buildout that uses the recipe looks like this:>>> write('buildout.cfg',
... """
... [buildout]
... parts = minify
...
... [minify]
... recipe = collective.recipe.minify
... paths =
...    ${buildout:directory}/src/foo
... ignore =
...      firm*
... include-devel = false
... """)Running the buildout gives us:>>> print system(buildout)
Installing minify.
Generated script '/sample-buildout/bin/minify'.
<BLANKLINE>Running this script minifies all JavaScript and CSS resources found in
the specfied locations. It walks all the paths specified ignoring all files
matching one of the patterns specified in ignore.ContributorsTom Gross, AuthorChange history1.0 (2010-01-05)initial release
[Tom Gross]Download
Package: collective.recipe.mockedeggs
SupportDocumentation:http://pypi.python.org/pypi/collective.recipe.mockedeggsCode repository:https://svn.plone.org/svn/collective/collective.recipe.mockedeggs/trunkQuestions and comments to thomas.desvenain at gmail.comDetailed DocumentationUsageSometimes you can’t add eggs through your buildout engine or easy_install, for
example if some dev libraries are lacking on your system, or are too old, etc.But you can install module directly on your system using your system’s packaging
utility (port installpython-xxx,apt-getinstallpython-xxxor with.msiinstallers for Windows. In examplepython-ldaporlxmlare
somehow difficult to install on Windows using source eggs, and are usually
available as binary installers.Then, though you get all you need in your python environment, your buildout may
fail because an egg is missing.This recipe will make buildout believe that such missing eggs are available and
installed, when your app will use the system wide Pyhton packages you installed
by your way.Yes, I know you should usually not do this but sometimes there’s no other (easy)
way to have your buildout completed.How-toYou have to addON TOP OF YOUR PARTSacollective.recipe.mockedeggsrecipe part:[buildout]
parts = mocked-eggs
        other parts...

[mocked-eggs]
recipe=collective.recipe.mockedeggsThe recipe supports the following options:mocked-eggsThe list of eggs you want to mock, with their version number, as for
example:mocked-eggs =
    python-ldap=2.3.10
    Markdown = 1.7Example usageWe’ll start by creating a buildout that uses the recipe:>>> write('buildout.cfg',
... """
... [buildout]
... parts = mocked-eggs-test
...         zopepy
...
... eggs = mocked1
...        mocked2
...
... [mocked-eggs-test]
... recipe = collective.recipe.mockedeggs
... mocked-eggs =
...      mocked1=1.0
...      mocked2=  2.0
...
... [zopepy]
... recipe = zc.recipe.egg
... interpreter = zopepy
... eggs = mocked1
...        mocked2
...
... """)Running the buildout gives us>>> print 'start...\n', system(buildout)
start...
Installing mocked-eggs-test.
mocked-eggs-test: Mocked eggs mocked1, mocked2.
...

>>> import os
>>> os.path.exists('mocked-eggs-test')
True
>>> os.path.exists('mocked-eggs-test/fake-mocked1')
True
>>> os.path.exists('mocked-eggs-test/fake-mocked2')
True

>>> setup1 = open('mocked-eggs-test/fake-mocked1/setup.py').read()
>>> '1.0' in setup1
True
>>> "'mocked1'" in setup1
True
>>> binary = open('bin/zopepy', 'r').read()
>>> 'mocked-eggs-test/fake-mocked1' in binary
TrueContributors“Thomas Desvenain”, Author“Gilles Lenfant”, ContributorChange history1.0rc1 23/03/2010we can have spaces in mocked eggs declaration (myegg = 2.0 is allowed)better documentation [glenfant,tdesvenain]1.0a1 10/03/2010Initial release [tdesvenain]Created recipe with ZopeSkelDownload
Package: collective.recipe.moin
Introduction============''collective.recipe.moin'' is a `zc.buildout`_ recipe which createsa entry point for the wiki engine `MoinMoin`_Installation============It is very simple to use. This is a minimal ''buildout.cfg'' file:::[buildout]parts = wiki[wiki]recipe = collective.recipe.moinprotocol = wsgisitename = My Wikilanguage_default = enThis will create a folder in parts/ called ``wiki`` that contain the egg folder, the config file and the web server deployment file.When you have a previous config file you can use this::[buildout]parts = wiki[wiki]recipe = collective.recipe.moinconfig = /some/path/to/wikiconfig.pyprotocol = wsgiParameters==========* ``protocol``, Default: ``wsgi``This option create a script for the server deployment. Otrer options: ``fcgi``, ``cgi``* ``config``, Default: /path/to/parts/name_of_part/wikiconf.pyIf you don't specify a MoinMoin configuration file, the recipe create a basic config file with the parameters filled in the recipe conf.* ``title``, Default: ``My Wiki``The title of the Wiki app.Deployment==========The apache configuration for this buildout looks like this:::WSGIScriptAlias /mysite /home/me/buildout/parts/wiki/moin.wsgi<Directory /home/me/buildout>Order deny,allowAllow from all</Directory>Credits=======* `Erik Rivera`_, initial implementation.. _zc.buildout: http://pypi.python.org/pypi/zc.buildout.. _MoinMoin: http://moinmo.in.. _`Erik Rivera`: http://rivera.pro1.0 - Octuber 18, 2011---------------------* Initial release[erikriver]
Package: collective.recipe.mxbase
As there isn’t available eggs for Egenix mx base
(http://www.egenix.com/products/python/mxBase/). This recipe will download
the tarball, build it and link it for you inside your buildout.Usage:Define the recipe and add it to the buildout parts. Ex:[buildout]
   parts =
   mx-base
   ...

[mx-base]
   recipe = collective.recipe.mxbaseIf you use buildout for zope 2 don’t forget to add the created egg to your
zope2instance:[instance]
recipe = plone.recipe.zope2instance
...
eggs =
    ...
    egenix-mx-base
Package: collective.recipe.mxzopeda
This recipe is largely based on  collective.recipe.mxodbc, a recipe created by
Jarn to installed eGenix mxODBC 3.0.X. That recipe will install mxODBC 3.0 and
also build an mx.base package from source. For the Zope database adapter eGenix
releases prebuilt packages with mxODBC 2.1 and the Zope Database Adapter
included. That’s what this recipe is for.You can add this recipe to your buildout by adding a section like this:[mxzopeda]
recipe = collective.recipe.mxzopeda
license-key = puty-ourl-icen-seco-dehe-repl-ease
licsenses-archive = mxzopeda-licenses.zipThe licenses archive should be a zip file with one directory for every license
you want to use with the license key as file name and the license file you
got from eGenix for that code in the directory.The recipe tries to detect the correct platform to download the prebuilt
archive for, but has so far only been verified on Apple OS X universal systems
and Ubuntu server 8.10 for i686. Please report any problems if you encounter
problems with other architectures.
Package: collective.recipe.platform
ContentsLimitations:Example usageChanges:Code repository:http://github.com/gweis/collective.recipe.platformLimitations:The recipe currently only generates platform strings for darwin10 and darwin9.
Due to the simplicity of the recipe itself, it should not be hard ta add
further platform-prefixes. (Patches and other contributions are welcome).Example usageThis recipe provides a way of defining buildout variables which can be
referenced form other parts with platform specific values. It does not try
being intelligent and guess what values it should set, but gives the user full
control, with the drawback/advantage of keeping all settings in a single or
multiple configuration sections.But examples are probably a better explanation:>>> write(sample_buildout, 'buildout.cfg',
... """
... [buildout]
... parts = debug
...
... [platform]
... recipe = collective.recipe.platform
... environment =
... darwin10-environment =
...     CC=gcc-4.0
... flags =
... darwin9-flags =
...     CPP=cpp-4.0
...
... [debug]
... recipe = zc.buildout:debug
... env = ${platform:environment}
... flags = ${platform:flags}
... plname = ${platform:platform}
... """)Ok, we have a part called ‘debug’. This part just prints all given options
to stdout. In our case it uses values referenced in the platform part.The platform recipe looks for options starting with a platform prefix, taxes
the remainder of the option name and replaces the value.The result of a buildout running on OSX 10.6 (darwin10) is the following:>>> print system(buildout)
Installing platform.
Unused options for platform: 'darwin9-flags'.
Installing debug.
  env='\nCC=gcc-4.0'
  flags=''
  plname='darwin10'
  recipe='zc.buildout:debug'Changes:0.1 (2009-10-13)initial release
Package: collective.recipe.pydevproject
Detailed DocumentationMotivationPyDevis a Python IDE for Eclipse.Among many useful things ithighlights syntax errors, allowscode completionandcode navigation.
For these to fully work, it is necessary to configure the project’s external dependencies appropriately.This recipePyDev adds a newPyDev Projectto Eclipse.Thiszc.buildoutrecipe generates the two files that define a PyDev Project:.projectand.pydevproject.Apart from simple project configuration,
the recipe adds the eggs of your choice as external dependencies.
Their transitive dependencies are added as well.BenefitsUsually the PyDev Project files.projectand.pydevprojectare not good candidates for versioning.
The reason is that these can easily contain user specific information, like personal directory paths.
This recipe allows you to version, in a buildout file, the information necessary to generate these files.Configuring the PyDev Project external dependencies by hand is neither clear not easy.Users of Maven and Eclipse JDT might find this project build generation very familiar.(Don’t use Java? I thought every Eclipse user did.)UsageAdd your recipe configuration tobuildout.cfgand include it in${buildout:parts}. An example:[buildout]
...
parts = ... pydevproject

[pydevproject]
recipe = collective.recipe.pydevproject
name = my_project_name
src = src
python_version = python 2.7
python_interpreter = Default
eggs = any_egg_you_wantOptionsThese match the options of a PyDev Project.nameThe project name. This is just for Eclipse and can be anything you want.srcThe source folder, relative to the root of the project. Usuallysrc.(TODO: get this from ${buildout:develop} and setup.py)python_versionThe combination of interpreter and grammar version. E.g.python 2.7python_interpreterThe interpreter name, as configured in the the Eclipse Preferences for PyDev. UsuallyDefaultis fine.Remember to register at least one interpreter in Eclipse before using your project. That can be done inWindow > Preferences > PyDev > Interpreter - Python >New....eggsThe eggs that will be listed as external dependencies.
You don’t need to include transitive dependencies. This is done automatically.SourceSource code lives athttp://github.com/collective/collective.recipe.pydevproject.Change history0.1 (2012-12-01)Initial implementation.
[marciomazza]ContributorsMarcio Mazza [marciomazza]
Package: collective.recipe.realpath
Contents0.1 (2011-06-21)OverviewUsageLICENSE / CREDITSThis buildout recipe allows for a part containing fixed and/or relative
filesystem paths as configuration options; these options are normalized
in during the run of the part, making the real (full) filesystem path
of the referenced paths available for use by other parts.0.1 (2011-06-21)Initial release.OverviewThis recipe normalizes any option value for the part it manages if said
option value begins with ‘path.’ – such options are assumed to be
paths.  This recipe replaces relative paths of all sorts with real,
full system path to files or directories.This recipe is useful as a replacement for using non-part sections for
holding path configuration; instead, use a part with this recipe, and
both relative and absolute paths can be stored for use by other parts
in your buildout.UsageLet’s create a buildout with a single part containing the configuration
options we want to either preserve or normalize:>>> write('buildout.cfg',
... """
... [buildout]
... parts =
...     paths
...
... [paths]
... recipe = collective.recipe.realpath
... notpath.here = something else
... path.parent = ${buildout:directory}/..
... path.to.nowhere = /dev/null
... path.var = ${buildout:directory}/var
... """)We run this buildout…>>> print 'start', system(buildout) # doctest:+ELLIPSIS
start...
Installing paths.We can see that (only) the necesssary options have normalized path
values:>>> from os.path import dirname, realpath
>>> builddir = dirname(dirname(buildout))
>>> buildout_parent = realpath('%s/..'% builddir)
>>> cat('.installed.cfg') # doctest: +ELLIPSIS
[buildout]
...
[paths]
...
notpath.here = something else
path.parent = ...
path.to.nowhere = /dev/null
path.var = /sample-buildout/var
...LICENSE / CREDITSMIT-style license – See docs/COPYING.txt
Author: Sean Upton / University of Utah / upiq.org
Upstream:https://teamspace.upiq.org/trachttp://dev.plone.org/collective/
Package: collective.recipe.rebar
ContentsDetailed DocumentationSupported optionsExample usageContributorsChange history1.0.1 (2010-03-10)1.0.0 (2010-03-09)DownloadCode repository:https://code.launchpad.net/collective.recipe.rebarQuestions and comments tohttps://answers.launchpad.net/collective.recipe.rebarReport bugs athttps://bugs.launchpad.net/collective.recipe.rebarDetailed DocumentationSupported optionsThe recipe supports the following options:erlang-pathThe path where to find the erlc command.urlThe URL to download the source distribution.Example usageWe will define a buildout template used by the recipe:>>> buildout_cfg = """
... [buildout]
... parts = riak
... offline = true
...
... [riak]
... recipe = collective.recipe.rebar
... url = http://bitbucket.org/basho/riak/downloads/riak-0.8.1.tar.gz"""We’ll start by creating a buildout:>>> import os.path
>>> write('buildout.cfg', buildout_cfg)Running the buildout gives us:>>> output = system(buildout)
>>> if output.endswith("==> riak (install)\nInstalling: riak-0.8\n==> erlang_js (install)\nInstalling: erlang_js-0.1\n"): True
... else: print output
TrueContributorsAli Sabil, AuthorChange history1.0.1 (2010-03-10)Improved the documentation1.0.0 (2010-03-09)Created recipeDownload
Package: collective.recipe.ropeproject
Detailed DocumentationMotivationRopeis a great tool for python development.It is arefactoring librarywith the marvelous side effect of letting you navigate throughout code.You can use it with eitheremacsofvimThis recipeThiszc.buildoutrecipe makes a.ropeproject folderwith search paths pointing to the eggs of your choice… and their transitive dependencies!BenefitsMake rope both faster and more precise.[1]The reason is that search paths are setexplicitly,
so rope does’t have to guess through directory hierarchies.A very good complement to theomelette recipe.
Actually, code navigation is way easier that grepping. Give it a try.[1]This statement has not been evaluated by the FDA.UsageIn your buildout.cfg include the recipe, with the eggs property set to one or more eggs:[buildout]
...
parts = ... ropeproject

[ropeproject]
recipe = collective.recipe.ropeproject
eggs = ${anything_you_want}SourceSource code lives athttp://github.com/collective/collective.recipe.ropeproject.git.Change history1.0b3 (2012-07-02)Moved repo tohttps://github.com/collective/collective.recipe.ropeprojectDelivered to PyPI1.0b2 (2012-07-01)Tests added.1.0b1 (2012-05-13)Initial implementation.
[marciomazza]ContributorsMarcio Mazza [marciomazza]
Package: collective.recipe.rsync
collective.recipe.rsyncis azc.buildoutrecipe that copies files between two locations via thersyncprogram.Notecollective.recipe.rsyncassumes you have a UNIX-based operating system and thersyncbinary is in your PATH when you run Buildout or thersyncscript.InstallationAdd a new section to yourbuildout.cfgfile to use thecollective.recipe.rsyncrecipe, e.g.:[buildout]
extends = https://raw.github.com/plock/pins/master/plone-4-3
parts += backup

[backup]
recipe = collective.recipe.rsync
source = ${buildout:directory}/var/filestorage/Data.fs
target = /var/backupThis copies a Plone Data.fs file from thesourceto thetarget.Create a scriptNormallycollective.recipe.rsyncwill runrsyncduring the recipe installation. Optionally you can create a script to executersynclater by configuring thescript = trueoption e.g.:[backup]
recipe = collective.recipe.rsync
source = ${buildout:directory}/var/filestorage/Data.fs
target = /var/backup
script = trueThis is useful in cases where you want to automate anrsyncscript with cron e.g. viaz3c.recipe.usercrontab.Configure optionsThe default options are-av--partial--progress. Use theoptionsparameter to change them e.g.:[backup]
recipe = collective.recipe.rsync
source = ${buildout:directory}/var/filestorage/Data.fs
target = /var/backup
# Omit "-v" option
options = -a --partial --progressExclude filesYou can exclude files with theexcludeoption e.g.:[backup]
recipe = collective.recipe.rsync
source = ${buildout:directory}/var/filestorage/Data.fs
target = /var/backup
exclude = Data.fs.index Data.fs.oldSpecify alternate SSH portOptionally you may specify an alternate SSH port forrsyncto use e.g.:[backup]
recipe = collective.recipe.rsync
source = ${buildout:directory}/var/filestorage/Data.fs
target = /var/backup
port = 2222Changelog2.3.0 (2019-03-21)Python 3 fix [petschki]2.2.2 (2014-02-23)Bug fix: provide all parameters to script option unless None2.2.1 (2014-02-23)Bug fix: provide all parameters to script option2.2.0 (2014-02-23)AddexcludesupportNone have quote around when script option is use and port is not in use. Fixes #3
[bsuttor]2.1.0 (2012-04-09)Clean up package2.0.0 (2011-05-24)Don’t prefix scripts with “rsync-”1.9 (2011-04-12)Call install on updateUI tweaks1.8 (2011-03-29)Switched to using subprocess to call rsync (to show progress to stdout)
[mattss]Replace print statements with loggerUpdate docs1.7 (2011-01-21)Doc fixesMake script name based on section nameSupport more than one script in the same buildout1.6 (2011-01-20)AddscriptoptionGenerates bin/rsync scriptDisables rsync during buildout executionFacilitates creation of scheduled rsyncs via cron1.5 (2011-01-10)Add a note about UNIX compat only1.4 (2011-01-10)Support alternate sshportparameter in recipe section. This allowscollective.recipe.rsyncto execute rsync with: -e ‘ssh <port>’, which facilitates copying over non-standard ssh ports.1.3 (2010-12-19)Fix docs1.2 (2010-12-19)Fix docsAdd new test harnessClean up package1.1 (2010-11-05)Modified output to include rsync command line being executed1.0 (2010-02-28)Rename package from collective.recipe.rsync_datafs to collective.recipe.rsync0.1 (2009-08-26)Created recipe with ZopeSkel