Saravanan666/pypi-org huggingface dataset:
Package: buildout.requirements
A simple buildout extension that creates a requirements.txt file for pip.This is a fork of buildout.requirements which is more or less a copy of
buildout.dumprequirements. All credit goes to the authors of that project.Warningbuildout.dumppickedversions(and therefore alsobuildout.dumprequirementsand
alsobuildout.requirements) does somenastystuff to get its job done. Namely
it monkeypatcheszc.buildout.easy_install._log_requirement,zc.buildout.easy_install.Installer._get_distandlogging.shutdown. Because both
extensions monkeypatch the same methods, it is currently not possible to usebuildout.dumppickedversionsandbuildout.dumprequirementsat the same time.
I’m not quite sure how to solve this. Probably we’ll have to support the functionality
of both extensions in one package.UsageAddbuildout.requirementsas an extension to the[buildout]section:[buildout]
extensions = buildout.requirements
dump-requirements-file = requirements.txt
overwrite-requirements-file = truedump-requirements-filedefines the file the requirement list will be written to. If it is undefined the
package list will be printed to the console. Settingoverwrite-requirements-filetofalsewill preventbuildout.dumprequirementsfrom overwriting an existing file. The setting defaults totrue.ContributorsYves Müller, port to Python 3 and Buildout 2Stefan Foulis, Author of buildout.dumprequirementsMustapha Benali, Author of buildout.dumppickedversions
Package: buildout.sanitycheck
Introductionbuildout.sanitycheckperforms sanity checks on the buildout
environment, cancelling the buildout if continuing might
be unwise.Checks performed:Make sure buildout is not being run as superuser.Changelog1.0.2 2015-06-161.0.1 was brown bag.1.0.1 2015-06-16Fix typo: “sudu” –> “sudo”1.0Initial release
Package: buildout_script
Author:Nathan R. Yergler <nathan@yergler.net>Copyright:2006-2015, Nathan R. Yergler, Creative Commons;
licensed to the public under theMIT license.Overviewbuildout_script is azc.buildoutrecipe for generating scripts from
a template.  Unlike scripts specified by theconsole_scriptsentry point, those generated by buildout_script are not restricted to
Python code.Scripts are generated from templates and can include settings from the
buildout substituted at runtime.One example usage is the generation of a wrapper script forPaste
Scriptto check the status of a
daemonized server process (see paster-check below).UsageTo use the buildout_script recipe, specify it as the recipe for a
zc.buildout part along with thetemplatepart.  For example:[sample_part]
recipe = buildout_script
template = paster-check.sh.inThe script will be created in the bin-directory.  You may also specify
the following parameters:targetThe filename for the generated script; if omitted, the script will have
the template filename without the extension.template_dirAn optional directory to look for templates in.  Default:templatesTemplates included with the recipe may also be used without specifying
a template_dir.TemplatesTemplate variables should be formatted using the buildout convention
of${part-name:variable-name}.NB. Until version 0.2a1 of buildout_script the pythonstring formatting syntaxwas used
where the dictionary for the formatting operation was a flattened dictionary of the
buildout settings and part settings.For example, a trivial script template to list the files in the buildout
installation directory would look like this:#!/bin/bash

# Sample buildout_script script template
ls ${buildout:directory}buildout_script ships with one script template,paster-check.sh.in,
described below.  Additional template contributions are welcome.paster-check.sh.inAt Creative Commons we usedPaste Scriptas the server for simple
web applications.  We run them using the--daemonflag, but
occassionally something goes awry and the process dies.  This template
generates a script which can be called periodically from cron to
ensure the process is still running.  Note that this script can also
be used to start the server if it is not already running.Configuration ParametersConfiguration parameters used by this script, which should be specified
as settings in the zc.buildout part:server_cfgThePaste Deployconfiguration
file to serve.pid_fileThe PID file to use when starting the server (and to subsequently check).log_fileThe log file to use.Change History0.3.1 (2017-03-06)Fix packaging issuesCHANGES.rst was referenced by setup.py, but not included in the package.0.3 (2015-10-12)PyPI release of changes contributed by jjmurre0.2a3 (2015-10-08)Templating syntax now cf. buildout, e.g. ${buildout:directory} NB. backwards incompatible!0.2a2 (2015-10-07)Fixes to make recipe work with modern pythons (>=2.7)0.2a1 (2007-03-14)Implementedtemplaterecipe for creating a non-executable file.0.1 (2006-12-12)Initial public releaseDownload
Package: buildout.sendpickedversions
buildout.sendpickedversionsThis package is based onbuildout.dumppickedversionsand its purpose is to
gather the package name and version information from buildout. The main
difference withbuildout.dumppickedversionsis that instead of displaying
picked versions, or dumping everything to a file, we’ll send package information
to a predefined URL.Original use case is that there isWhiskersserver on the other end which stores
the data. There’s nothing special about the data, so other end can just as well
be anything that can handle json.ConfigurationTo use buildout.sendpickedversions with buildout your buildout.cfg should have
buildout.sendpickedversions in you extensions-line and following fields
configured:buildoutnameThis is the name of the buildout.Whiskersuses this information to create
new buildout object with the package data. If name is not set we use default
‘dummy_buildout’ as a name.whiskers-urlThis is the url to whiskers server. As stated above, you can use here
anything that can just eat the json-data we’re sending. If you leave this
empty or don’t set at all buildout.sendpickedversions just displays the data
dict.ExampleHere’s small example configuration.[buildout]
extensions = buildout.sendpickedversions
buildoutname = test
whiskers-url = http://localhost:6543/buildouts/add

parts = nose

[nose]
recipe = zc.recipe.egg
eggs = noseAbove example configuration assumes you haveWhiskersserver running locally on
port 6543. If you run buildout it will install nose normally to your buildout
environment and after everything is ready it will try to send following data in
json-format to localhost:6543/buildouts/add URL:{"buildoutname": "test",
 "packages": [
    {"version": "0.6.24", "name": "distribute"},
    {"version": "1.18", "name": "mr.developer"},
    {"version": "1.1.2", "name": "nose"},
    {"required_by": ["mr.developer 1.18"], "version": "1.5.2", "name": "zc.buildout"},
    {"version": "1.3.2", "name": "zc.recipe.egg"}
  ]
}ThanksCode is mainly based to Mustapha Benali’sbuildout.dumppickedversions. This
buildout extension has probably saved thousands of buildouts from nasty version
conflicts or total havoc. Huge thanks!Changelog0.3 (2012-10-11)Performance optimizations (ported from zc.buildout).0.2 (2011-10-16)Sends data urlencoded.0.1 (2011-10-16)Initial import
Package: buildout.threatlevel
buildout.threatlevelAll … should continue to be vigilant, take notice of their
surroundings, and report suspicious items or activities to local authorities
immediately.—the U.S. Department of Homeland Securitybuildout.threatlevelis a buildout extension which will report on the
success of your buildout to the globalBuildout Threat Levelindicator.It will also report the current threat level, based on the percentage of
buildout runs that have succeeded for all users of buildout.threatlevel over
the past 4 hours.Usage:[buildout]
extensions = buildout.threatlevelChangelog1.1 (2010-03-05)Fix issue where failure resulted in an erroneous positive result that
canceled out the negative one.
[davisagli]1.0 (2010-03-04)Initial release.
[davisagli]
Package: buildout-tox
This is a buildout recipe to build and test packages in multiple
environments. It is inspired by Holger Krekel’s excellentToxpackage forvirtualenvbut focuses instead on package development
usingbuildout.WarningThis package is not currently being developed and was never
completed!The author discovered that Tox itself can be used with buildout and
provides a good way of checking that package distributions contain
what is required.For an example of this usage pattern, see theTestFixturespackage.
Package: buildout.ucsdetector
buildout.ucsdetector********************The buildout.ucsdetector is a buildout extension that allows define diferentlinks according to the UCS (Unicode Character Set) used by the python executableassociated with the buildout process. It's a workaround to provide a way toinstall a project with that uses C/Python Unicode API internally and have toprovide support for diferent Python Unicode installations.At the moment, Python 2.x versions have two python unicode support: UCS2 andUCS4.More details about the problem can be found at the `Python Documentation<http://docs.python.org/c-api/unicode.html>`_.Available Options*****************- ucs2-linksDefine which dependency links will be added at the find-links option ifthe python process if UCS2 enabled.- ucs4-linksDefine which dependency links will be added at the find-linksoption if the python have UCS4 support.
Package: buildout.umask
IntroductionThis extension allows better control over the initial permissions of files created by buildout by allowing the umask used by the buildout script to be specified in the configuration file.Because of bug180705of zc.buildout, this doesn’t work for scripts installed by buildout.This doesn’t affect the umask of other scripts in the buildout, unless
they set their own the umask of the user running them will be used,
e.g.: ZEO/Zope might still make var/filestore/Datafile.fs world
readable if your umask is 022.Usage[buildout]
extensions = buildout.umask
umask = 027Theumaskparameter can be specified using any of Python conventions
for numeric literals of binary, octal, decimal or hexadecimal
radix. If any of them is used and a0is the first digit, octal is
assumed as well.QuestionsThe code is quite simple, take a glimpse.Bugshttps://bugs.launchpad.net/buildout.umaskChangelog0.5.2 (2010-12-02)Documentation fixes.0.5.1 (2010-12-02)Fix packaging by using setuptools_bzr.0.5 (2010-12-01)First public release0.1 (unreleased)Initial version.
Package: buildout.variables
buildout.variablesProvides dynamic variables in buildouts.An example use are unique DB names and conflict free parallel continuous integration runs on one machine.Example buildout section:[variables]
recipe = buildout.variables
index-file = ${env:HOME}/jenkins-buildout-index.json
index-start = 0
index-key = ${env:JOB_NAME}
portbase = indexed 12{index}00
port = int portbase 0:100
port-instance = new port
jobname = str "${env:JOB_NAME}" [^a-zA-Z0-9] _

[env]
recipe = gocept.recipe.envThere are several things going on here.The first are theindex-options. They provide you with the possiblity to get unique indices based on a key and stored in a shared file. That way each buildout gets the same index for each key used. In the example above the key is the JOB_NAME environment variable (set by Jenkins for example) and the index starts at 0. If a buildout with a different JOB_NAME is run, then it will get the next free index.Theportbaseoption evaluates “12{index}00”.format(index=index). Thus the
first job will get 12000 and the second job 12100 and so on.Theportoption declares a range of integers which can be used to get unique ports for whatever you need them for. Theport-instanceoption uses that to declare a port which can be used with ${variables:port-instance} throughout the buildout and would be 12000 in this example. If you declare more, then up to 12099 will be possible before you get an error. Which variable
gets which port is determined by lexical order of the variable name.Thejobnameoption takes ${env:JOB_NAME} and runs re.sub on it. In this example everything besides letters and numbers is replaced by an underscore.Besides integer ranges you can’t use other dynamic variables from the same section.CreditsThanks to Legacy Parts Corporation andhttp://enquos.comfor which this package was initially created.Changelog0.3 - 2013-03-15First official release.
[fschulze]0.2 - UnreleasedFix persisted index.
[fschulze]0.1 - UnreleasedInitial version.
[fschulze (Florian Schulze)]
Package: buildout-versions
This is a buildout extension that provides three functions:Output to the console of any versions not pinned in the buildout configurationThe optional appending of any versions not pinned in the buildout configuration to a specified file.Make buildout agnostic of the casing used in distribution names.For full documentation, please seehttp://packages.python.org/buildout-versions/use.html.This package takes a lot of inspiration frombuildout.dumppickedversions.
Package: buildout.wheel
Experimental Buildout extension to provide wheel supportTo get wheel support in Buildout 2.8 or later, include the buildout
wheel extension:[buildout]
extensions = buildout.wheel
...Changes0.2.0 (2017-03-12)Make use of newer support in buildout for per-extension binary dist UNPACKERs
for a much cleaner implementation of wheel support.Also, make use of newer support in buildout for installed non-egg
distributions to get rid of humpty as dependency. Wheel packages will be
installed as.ovodirectories insideeggs-directory.0.1.2 (2017-02-13)Initial release
Package: buildparser
BuildParser===========A [specification](SPECIFICATION.md) and parser for project build configuration.## Setup### pip```bashpip install buildparser````### git```bashgit clone git://github.com/brettlangdon/buildparser.gitcd ./buildparserpython setup.py install```## Basic Usage```pythonimport buildparserbuilds = buildparser.parse("./path/to/project")for build in builds:print build.envprint build.before_buildprint build.buildprint build.after_buildprint build.after_successprint build.after_failure```## API### Environment(object)#### Properties* `type` - string* `options` - mixed#### Methods* `__init__(self, type, options)`* `__repr__(self)`* `as_dict(self)`* `as_json(self)`* `as_yaml(self)`### Script(object)#### Properties* `commands` - list#### Methods* `__init__(self, commands)`* `__repr__(self)`* `as_dict(self)`* `as_json(self)`* `as_yaml(self)`### Build(object)#### Properties* `env` - Environment* `before_build` - Script* `build` - Script* `after_build` - Script* `after_success` - Script* `after_failure` - Script#### Methods* `__init__(self, env, before_build, build, after_build, after_success, after_failure)`* `__repr__(self)`* `as_dict(self)`* `as_json(self)`* `as_yaml(self)`## UnknownExtensionException(Exception)## parse(directory, name="build")*returns*: listLook for an appropriate `name` file or directory in the directory `directory`and parse all possible build configurations found.`parse` defaults to looking for the following files:* `.build.yml`* `.build.yaml`* `.build.json`* `.build.ini`* `.build.cfg`or for the directory `.build` which contains one or many configuration files(name doesn't have to be "build").## parse_directory(dir_name)*returns*: listLook for all appropriate files inside of `dir_name` and parse configurations found.## parse_file(file_name)*returns*: listParse any available build configurations from `file_name`## parse_yaml(file_name)*returns*: listParse any available build configurations from `file_name` as though it was yaml.## parse_json(file_name)*returns*: listParse any available build configurations from `file_name` as though it was json.## parse_ini(file_name)*returns*: listParse any available build configurations from `file_name` as though it was an ini file.
Package: buildprint
BuildprintObjectives:High-level abstraction on top of builkditehttps://buildkite.com/blog/how-bazel-built-its-ci-system-on-top-of-buildkitehandles sharding nativelyhttps://github.com/philwo/bazel-utils/blob/main/sharding/sharding.pyfor referenceSuppports a culprit finder (stretch goal)Can run locallyThis might be obsolete if I can figure out how to execute a pipeline with the buildite-agent locallyTwo staged upload:git-based "smoke tests" then bazel-based full suite.ideally this is one step with the git-based operations in the backgroundany way to immediately determine bazel is unrequired is a +This need bazel-diff integration to this endIf it does, consider using worktrees to execute bazel-diff inhas a public schema that can be used for validationproto-backed?
Package: buildprof
Introductionbuildprof is a tool that can generate and view build profiles.
It parses the output of the standard command ‘top -b’, and the statistics files
generated by ccache > 3.0.It generates a chart with the cpu, memory usage and ccache hit/miss rate over time.By passing the mouse cursor over the graph, you can see the process that were running at
that time on the machine, and see what’s going on when the cpu is not 100% utilised.Installationbuildprof uses the standard python library and has no other dependancies.
It embeds an html5 application to view the results.sudopipinstallbuildprofUsagebuildprof-obuildprof_results.htmlmake-j4This will run your make -j4, and then open a browser with the results.
Package: build.py
build.pybuild.py is a simple build system written in python.Just create abuild.pywith the following content:#!/usr/bin/python3importbuildbuild.main(__name__)classConfig(build.Config):# Put your options here# Defaults:# Default taskdefault='build'# Languages to build (lang/<lang>.py)languages=[]# Default output directoryout='out'# Whether to preserve output paths (src/dir/file.py -> out/dir/file.py or out/file.py)preserve_paths=True# Enable builtin tasks (build etc.)builtins=True# Or remove the class above and put your options hereThen call./build.py -husage:build.py [-h] [-f FILE] [-o OUT] [task] [args [args ...]]positional arguments:OptionDescriptiontaskThe task that should be calledargsThe arguments for TASKoptional arguments:ShortLongDescription-h--helpShow this help message and exit-f FILE--file FILEThe build configuration-o OUT--out OUTThe output directory
Package: buildpy-server
Buildpy-ServerBuildpy-server is a reliable build server.FeaturesFirst prototype release on Pypipluggy based plugin architecturerun builds inside configurable environmentsRequirementsPython >= 3.4InstallationYou can install “buildpy-server” viapipfromPyPI:$ pip install buildpy-serverLicenseDistributed under the terms of theMITlicense, “buildpy-server”
is free and open source softwareIssuesIf you encounter any problems, pleasefile an issuealong with a
detailed description.Changelog0.1.0 (2016-02-15)various additions to documentationclean packagefirst prototype release on Pypi0.0.3 (2016-01-05)dynamically create changelogadd option hooksadd version option
Package: buildpy-server-envs
Buildpy-server-envsis a plugin forbuildpy-server.
A simple plugin to use with Buildpy-Server.InstallationYou can install “buildpy-server-testcommands”
viapipfromPyPI:$ pip install buildpy-server-envsLicenseDistributed under the terms of theMITlicense,
“buildpy-server–environments” is free and open source software.IssuesIf you encounter any problems, pleasefile an issuealong with a detailed description.
Package: buildpy-server-testcommands
Buildpy-server-testcommandsis a plugin forbuildpy-server.
It provides running test commands.InstallationYou can install “buildpy-server-testcommands”
viapipfromPyPI:$ pip install buildpy-server-testcommandsLicenseDistributed under the terms of theMITlicense,
“buildpy-server-testcommands” is free and open source software.IssuesIf you encounter any problems, pleasefile an issuealong with a
detailed description.
Package: buildstr
Fancy Pythonic String BuilderFree software: Apache Software License 2.0FeaturesBuilds strings in a pythonic way.We're using thewithstatement to build substrings.Python code can be interleaved with the string building.Useful for generating code.ExamplefrombuildstrimportBuilderb=Builder("A")b<<"B"withb(surround=("{ "," }"),separator="; ")asb1:b1<<["a","b","c"]assertb.build()=="A B { a; b; c }"
Package: buildstrap
Buildstrap: generate a buildout config for any *env projectThere’s pyenv, pyvenv, venv, virtualenv… and who knows how many other
ways to deal with development of python programs in a per-project
self-contained manner.While most of the python community tried to keep up, and got their shell
configuration or global pip changing regularly, some have been quietly
enjoying python development the same way for the last ten years, usingbuildoutfor their
development.Though, it’s a fact that buildout is not the standard way to do things,
even if it’s a very convenient tool. So to keep your repositories
compatible with most *env tools available — or get buildout with other
projects. I wrote this tool to make it easy to create a buildout
environment within the project.Quickstart GuideHere we’ll see the most common usages, and refer tothe full
documentation for more details.Usagewhen you got a repository that has requirements files, at the root of
your project’s directory, call buildstrap using:% buildstrap run project requirements.txtwhereprojectas second argument is the name of the package as
you’ve set it up in yoursetup.py— and as you’d import it from
other python code.Running that command will generate thebuildout.cfgfile, and runbuildoutin your current directory. Then you’ll find all your
scripts available in the newly createdbindirectory of your
project.If you have severalrequirements.txtfiles, depending on the task
you want to do, it’s easy:% buildstrap run project -p pytest -p sphinx requirements.txt requirements-test.txt requirements-doc.txtwhich will create three sections in yourbuildout.cfgfile, and get
all the appropriate dependencies.Here’s a real life example:% git hub clone kennethreitz/requests    # cf 'Nota Bene'
% cd requests
% buildstrap run requests requirements.txt
…
% bin/py.test
… (look at the tests result)
% bin/python3
>>> import requests
>>>or another one:% git hub clone jkbrzt/httpie            # cf 'Nota Bene'
% cd httpie
% buildstrap run httpie requirements-dev.txt
…
% bin/py.test
… (look at the tests result)
% bin/http --version
1.0.0-devInstallationit’s as easy as any other python program:% pip install buildstrapor from the sources:% git hub clone guyzmo/buildstrap
% cd buildstrap
% python3 setup.py installDevelopmentfor development you just need to do:% pip install buildstrap
% git clone https://github.com/guyzmo/buildstrap
% cd buildstrap
% builstrap run buildstrap -p pytest -p sphinx requirements.txt requirement-test.txt requirement-doc.txt
…
% bin/buildstrapYeah, I’m being evil here 😈You can have a look at thesources
documentation.Nota BeneYou might wonder where does thegit hub clonecommand comes from,
and I’m using here another project I wrote:guyzmo/git-repo.Simply put,git hub clone user/projectis equivalent togit clonehttps://github.com/user/project.LicenseCopyright © 2016 Bernard `Guyzmo` Pratz <guyzmo+buildstrap+pub@m0g.net>
This work is free. You can redistribute it and/or modify it under the
terms of the Do What The Fuck You Want To Public License, Version 2,
as published by Sam Hocevar. See the LICENSE file for more details.
Package: buildtest-configs
buildtest-frameworkDescriptionThe buildtest repository is anAutomatic Test Generation Frameworkfor writing test cases suited to work well in a HPC environment.  This framework heavily relies that your application is built withEasyBuildand your system hasLmodorEnvironment Modulesfor managing modulesDocumentationPlease seebuildtest documentationfor more details.Contactemail:shahzebmsiddiqui@gmail.com
Package: buildtest-framework
buildtest-frameworkDescriptionThe buildtest repository is anAutomatic Test Generation Frameworkfor writing test cases suited to work well in a HPC environment.  This framework heavily relies that your application is built withEasyBuildand your system hasLmodorEnvironment Modulesfor managing modulesDocumentationPlease seebuildtest documentationfor more details.Contactemail:shahzebmsiddiqui@gmail.com