Saravanan666/pypi-org huggingface dataset:
Package: infractl
Infrastructure Control LanguageTool to easily run your data science, machine learning or deep learning experiments anywhere: locally, on-prem clusters, or hybrid clouds.
Based on Infrastructure as Code, but pushed to the next level.
Provides cosmic level of infrastructure control bringing old good days back when you run program on the machine you develop.Still in engineering Alpha mode. Use with caution. But let us know what you think!Quick startThe simplest way to start with ICL is to create a local ICL cluster in a Docker container:gitclonehttps://github.com/intel-ai/icl.gitcdicl
./scripts/deploy/kind.shThe cluster's endpoints are accessible only from localhost:http://jupyter.localtest.mehttp://dashboard.localtest.mehttp://minio.localtest.mehttp://prefect.localtest.meIn your browser, navigate tohttp://jupyter.localtest.me.Install Python packageinfractlpackage withpip:pipinstallinfractlICL allows running a local Python program ofPrefectflow in a cluster.Create a Python filemy_program.py:if__name__=='__main__':print('Hello from my_program')Then execute the program in your cluster:importinfractlawaitinfractl.run(infractl.program('my_program.py'))Create a Python filemy_flow.pywith Prefect flow definition:fromprefectimportflow@flowdefmy_flow():print('Hello from my_flow')Then execute the flow in your cluster:importinfractlawaitinfractl.run(infractl.program('my_flow.py'))Note that the program and flow can be developed, tested, and executed locally.
ICL allows executing the same program or flow in your local or remote ICL cluster.Next stepsIn addition to a local ICL cluster, there are scripts to create multi node ICL clusters in AWS, GCP.
We also support deploying ICL into an existing Kubernetes or OpenShift clusters, provisioning bare-metal machines.
Check our documentation athttps://intel-ai.github.io/icl/.
Package: infrae.buildout
Used to run a sub-buildout in a buildout. Example:[cms]
recipe = infrae.subversion
urls = https://svn.infrae.com/buildout/silva/trunk .

[cms-build]
recipe = infrae.buildout
path = ${cms:location}
config = profiles/test-instance.cfg
merge-bin = TrueThecmspart fetch buildout files, here from a SVN. You can useinfrae.pasterto create a buildout tree using a paster template.Thecms-buildpart runs buildout on thecmspart:Thepathoption determines which parts to depends on, and which
path to use. This is important to use the${cms:location}because this says to buildout that thecms-buildparts depends
on thecmsone. This parameter is required.Theconfigoption tells which configuration file to use in thepath. By default it willbuildout.cfg, but you can use
safelyprofiles/something.cfg(buildout directory is configured
to use thepathfolder to run himself).Themerge-binoption tells if the generated scripts of the
sub-buildout should end up in the same directory than the current
one. The default isFalse.DisclaimerThe sub-buildout is run in the main parts directory in this sample. If
this sub-buildout contains data (in avarfolder for example),
they will end-up in the same part directory than the sub-buildout
(useless specific configuration in this one). This implies if you
update your main buildout and the main parts directory is deleted,your data would be lost.Latest versionThe latest version is available in aSubversion repository.
Package: infrae.cache
This packages includes several utilities to work with caching.It provides the following beaker backend extension:nocache: as it name says, do not cache (for testing),memorylru: a memory backend that use the LRU stategies, that is close to
the strategy memcache use.CHANGES1.0.1 (2010-10-06)Fix no cache implementation.1.0 (2010-10-06)Initial release.
Package: infrae.comethods
This package provides an helper to write cofunction with the help of
Python generators. It provides a decorator that let you write the
following paradigm:from infrae.comethod import cofunction

@cofunction
def processor(**options):
    # Init code
    content = yield
    while content is not None:
         # Work on content, set result in result.
         content = yield result
    # Cleanup codeIf you create more of those comethods you can nest them:import logging

@cofunction
def logger(parent **options):
    logger = logging.getLogger(options.get('name', 'default'))
    logger.info('Start')
    content = yield
    while content is not None:
         result = parent(content)
         logger.info('Processed {0}, got {1}'.format(content, result))
         content = yield result
    # Cleanup code
    logger.info('Done')And you can use it like this:with processor() as process:
   with logger(process) as log:
      for item in generator():
          log(item)Or alternatively:with processor() as process:
   with logger(process) as log:
      log.map(generator)Where generator is a generator that yield values to work on. Of
course, you can do more interesting things after.You can find the Mercurial code repository at:https://hg.infrae.com/infrae.comethods/Changes1.0 (2011/11/07)Initial version.
Package: infrae.fileupload
infrae.fileuploadis a WSGI component that can be used as a
middleware in order to intercept single file upload and save them on
the disk. The request to the application is then replaced by a json
body describing the information about the file. The original filename
and mimetype sent by the browser are kept as metadata. In addition to
this, it is possible to query the status of the upload and reset it
with HTTP request (by appending/statusto the upload URL). An API is
exposed via theenvirondictionnary provided the WSGI application
and can be used in order to query the files.The API provides the following methods:create_identifier()Create a new upload identifier that be provided while submitting
the form using theX-Progress-IDparameter in the URL.verify_identifier(identifier)Validate a given identifier.access_upload_bucket(identifier)Access the given upload. An object with the following methods is
returned:get_status()Return a dictionnary containing metadata information about the upload.get_filename()Return the filename of the uploaded file.is_complete()Return True if the upload was complete.clear_upload()Delete the upload.clear_upload_bucket(identifier)Delete the given upload.It is possible to use the component as a standalone WSGI application
and having a dedicated upload server available at a different URL.PasterThe upload middleware (and upload application) can be used via Paster
usingegg:infrae.fileupload. Configuration directives are:directoryPool directory where to store the uploaded files. If multiple
processes accross multiple servers are configured for the same URL, they
should share this directory too.max_sizeMaximum allowed size for an upload in megabytes.upload_urlURL where to upload the files. If not specified the URL specified
by the wsgi environment will be used. If it is specified, the
middleware won’t intercept uploads and assume this task is handled
by the given URL. This is use in large installation in order to
have a dedicated upload server by using the standalone application
instead of the middleware. Upload URLs always ends with/upload. If it is not the case it will appended to it.upload_keyPrivate key used to hash upload identifier. This enable a basic
security preventing abuse of the upload middleware or
application. If multiple processes and installations shares the
same upload URL they should share the same upload key too.Changes1.0.1 (2013/10/09)Support malformed requests that are not properly terminated.1.0 (2013/10/08)Initial release.
Package: infrae.i18nextract
infrae.i18nextractis a buildout recipe which create a script to
extract i18n strings from multiple packages into a.pot. A script
to merge  or compile all available translations is also available.The script support extraction from Python Script, Zope Page Template,
Chameleon Page Template, Formulator forms and Silva Metadata schemas.Exemple in buildout:[silva-translation]
recipe = infrae.i18nextract
packages =
   silva.core.views
   silva.core.smi
output = ${buildout:directory}
output-package = silva.translations
domain = silva
extra-paths = ${zope2:location}/lib/pythonOptionspackagesList of packages to extract translation from.outputOutput directory for the created template file.output-packageIf specified, you will be able to create the template file directly
inside that package.domainTranslation domain to use.zope-productsList of directories that contains Zope Products (Python packages
that must loaded using the import pathProductsrather than
their own).extra-pathsExtra python path to add in order to able to load the Python code
to extract translations strings from it.ScriptsTwo scripts are created:part-name-extractThat do extract the translations. The option-psaves the created
template file in theoutput-packagespecified in the buildout part.part-name-manageManage translation files in theoutput-packagespecified in the
buildout part:-mmerge the translation template file into all existing
translations files.-ccompile all existing translations files.The last script requires to have the commandsmsgfmtandmsgmergeinstalled on the system (available in gettext).Changes1.3.1 (2013-05-23)Add support to extract thetitleanddescriptionfields from
the Silva Metadata files.1.3 (2012-08-17)Add two options--export-tarballto create an archive that can
be used to upload translations to Launchpad, and--import-tarballthat can be used to import a tarball from
Lanchpad.Addzope-productsoptions to enable extraction in code that uses
old Zope products.1.2.1 (2011-02-07).xmlfiles are not always Silva Metadata. Don’t fail if they can’t
be parsed as such.1.2 (2010-10-06)Rename the merge script into manage. Add an option to compile
translation files.Fix logging output that was wrong when the translation contained
dots.1.1 (2010-04-26)Add support forextra-pathsso the recipe can be used with older
Zope version in buildout.Add a script to merge translations.1.0 (2010-04-02)Initial version, built from previous Infrae packagei18nextract-sa.
Package: infrae.layout
infrae.layoutdefines a way to write view that can reuse an
existing defined layout in Zope 2. It is similar tomegrok.layout,
and work the same way, with some additions.APIYou can define aLayoutthat will be used by aPage. APageis
a view and behave the same way. A page will look for Layout and will
render inside it.BothPageandLayoutcan be rendered by either arendermethod, or by an associated template, exactly like a Grok view.ALayoutis found by adapting the request and the content:
you can register layouts for your skin, then for a specific content.If this is not sufficient, a page can use the Grok directivelayoutto directly specify its type of Layout to use. While
defining your layout, you can use the same directive to declare which
layout a type belongs to. For instance if you have a skinICorpSkin:from infae.layout import layout, Layout, ILayout, Page
from five import grok

from corp.skin import ICorpSkin

grok.skin(ICorpSkin)


class ViewLayout(Layout):

   def render(self):
       return u'View %s' % self.view.content()

class Index(Page):

   def render(self):
       return self.context.title()Now if on the same content you want an edition layout for instance:class IEditionLayout(ILayout)
    """Layout to edit content
    """

class EditionLayout(Layout):
    layout(IEditionLayout)

    def render(self):
        return u'Edit %s' % self.view.content()

class Edit(Page):
   layout(IEditionLayout)

   def render(self):
        return self.context.title()If the above mecanism is not flexible enough for your application, you can
write an adapter on the request and your content that providesILayoutFactory.
The adapter will allow you to code the logic to select any layout you want.CHANGES1.0 (2010/07/16)Initial release.
Package: infra-enver
INFRA_ENVERexamplefrominfra_enverimportinfra_enverimportrandomif__name__=='__main__':env=infra_enver.Enver("galaxy","pass","localhost",2,"pass","https://service.com")# get settingprint(env.MY_SETT)# experimentforiinrange(10):print(env.get_experiment("TEST_EXP_2",random.randint(3,1000000)))
Package: infrae.paster
Create a part using paster. For example:[cms]
recipe = infrae.paster
template = plone3_buildout
zope2_install =
plone_products_install =
zope_user = admin
zope_password = admin
http_port = 8080
debug_mode = off
verbose_security = offThetemplateoption defines which paster template to use. Others
options are the one used by the template.Latest versionThe latest version is available in aSubversion repository.
Package: infrae.rest
infrae.restprovide a simple way to write REST APIs in Zope 2.APIREST componentinfrae.restprovides mainly a base classRESTwhich behave a
lot like a Grok view:from infrae.rest import REST

class MyAction(REST):
    """My action REST API.
    """

    def POST(self, name, value):
        # Called by POST /content/++rest++myaction&name=foo?value=bar
        return 'Success'

    def GET(self):
        # Called by GET /content/++rest++myaction
        values = self.context.something()
        return self.json_response(values)You just have to grok your package to make it available.You can provide:POST,GET,HEAD,DELETErequests.You can use the directivesgrok.name,grok.requireandgrok.contextto configure your REST API. They work exactly like
on agrok.View.If you need, you can manually query a REST component with the help
ofinfrae.rest.queryRESTComponent.Nesting REST componentYou can nest REST component. In that you should use the grok directive
adapts in order to define which is the parent handler, and the
context:from infrae.rest import REST
from five import grok
from OFS.Folder import Folder

class ParentHandler(REST):
    grok.context(Folder)

    def GET(self):
        # Called by GET /folder/++rest++parenthandler
        return u'Hello'


class ChildHandler(REST):
    grok.adapts(ParentHandler, Folder)

    def GET(self):
        # Called by GET /folder/++rest++parenthandler/childhandler
        return u'ChildRESTWithTemplate componentYou can alternatively use the base classRESTWithTemplate. The
only difference is that your class will be associated to a Grok
template automatically.RepositorySources can be found in Mercurial at:https://hg.infrae.com/infrae.restChanges1.3 (2013-05-23)Add support forstaticon aRESTWithTemplatecomponent.Update tests.1.2 (2012-09-04)Change registry for handlers fromzope.componenttozeam.component. This simplify the code base and brings more
flexibility. ExposequeryRESTComponentfunction.Remove usage of Zope 2shiftNameToApplication, as this is buggy
in recent Zope 2 releases.1.1 (2011-11-07)Add support for nested handlers.Add support forabsoluteURL, in order to get back the URL of an handler.Add a default component that is associated with a Grok template. You
have to trigger the template rendering yourself.An event is triggered when a handler is published. If the handlers
are nested, the event is only triggered for the last one. You can
see as publisher after traverse event, except you have access to the
associated handler that is published.We now use only the Python native json module (and no longer
simplejson).1.0.1 (2010-10-07)Don’t define response as a property to be compatible with other Zope views (as a mixin).1.0 (2010-07-15)Initial release
Package: infrae.uwsgi
Buildout recipe downloading, compiling and configuring uWSGI.Creates abin/uWSGIexecutable andpartsXML configuration
file with which you can easily launch Buildout sandboxeduWSGIprocesses.This recipe is a fork of shaunsephton.recipe.uwsgi, in order to update
it to work with recent versions of Buildout and UWSGI. All credits
goes to its original authors.ContentsUsageChangesUsageAdd a part to yourbuildout.cfglike so:[buildout]
parts=uwsgi

[uwsgi]
recipe=infrae.uwsgiRunning the buildout will download and compileuWSGIand add an
executable with the same name as your part in thebin/directory. In this casebin/uwsgi. It will also create auwsgi.xmlconfiguration file in apartsdirectory with the
same name as your part. In this casebin/uwsgi/uwsgi.xml.This allows you to start auWSGIprocess configured by the generated
XML file, i.e.:$ ./bin/uwsgi --xml parts/uwsgi/uwsgi.xmlThe generated XML configuration includespythonpathdirectives
referencing the various Python eggs installed by Buildout allowinguWSGIto utilize them.You can specify any and all additionaluWSGIconfiguration options as
additional options of the Buildout part. For instance to specify a
socket and module and to enable the master process addsocket,moduleandmasteroptions to the buildout part, i.e.:[buildout]
parts=uwsgi

[uwsgi]
recipe=infrae.uwsgi
socket=127.0.0.1:7001
module=my_uwsgi_package.wsgi
master=onYou can also provided a set of eggs explicitly using theeggsoption, i.e.:[buildout]
parts=uwsgi

[uwsgi]
recipe=infrae.uwsgi
download-url=http://projects.unbit.it/downloads/uwsgi-1.4.9.tar.gz
eggs=my_uwsgi_packageChanges1.0 (19-08-2013)Initial version as a fork ofshaunsephton.recipe.uwsgi. Update
the recipe to work with recent version of uwsgi and buildout,
improve the configuration options and prevent uwsgi to be downloaded
and compiled each time buildout is ran.
Package: infra-flow
INFRA_ENVERexamplefrominfra_enverimportinfra_enverimportrandomif__name__=='__main__':env=infra_enver.Enver("galaxy","pass","localhost",2,"pass","https://service.com")# get settingprint(env.MY_SETT)# experimentforiinrange(10):print(env.get_experiment("TEST_EXP_2",random.randint(3,1000000)))
Package: infragenie
:genie: InfraGenieInfraGenie is allows you to split out your infrastructure project into separate independent pieces, each with its own terraform state. This is done using a pattern similar to dependency injection in  programming languages, but under the hood it usesterraform data blocks.Why this pattern?There are several reasons why you would want to adopt this pattern:Flexibility in customising your infrastructure. We know that for a single project the infrastructure might change from one environment to another. For example if you are using an Elasticsearch service in production you might use a self-hosted version in dev to save costs. InfraGenie makes this process very easySplit your terraform state. By splitting your state accross several modules you can run several applies in parallel. It makes the terraform refresh faster. It also makes your applies safer since if some apply goes haywire it will only affect the resources in the current module.What about Terraform modules?Terraform modules can allow you to acheive some flexibiliy buy you still share state across the entire project. It is more difficult to make part of a module optional. Thecountsyntax and similarforeachdeclarative statements in terraform can be confusing if you are not used to the declarative style it uses.How it worksTo use infragenie you simply create a file calledgenie.hclin the root of your project and use it to define your pipeline.# genie.hcl# unified variables for use in all pipelinesvariables{project_name="myproj123"environment="dev"region="us-east-1"}# resource injections definitioninject{main_vpc={source=vpc.aws_vpc.vpc# source can come from any of the pipeline steps}}pipeline{steps=[{name="vpc"description="creates a vpc and 2 subnets"source="./vpc"},{name="ecs"description="creates an ecs cluster and SG"source="./ecs"},]}Now with this genie file you can use the vpc in any of your modules as a data definition:# ecs/main.tfresource"aws_security_group""ecs_service_sg"{# using global variablesname_prefix="${var.project_name}-${var.environment}"# using vpc from other module as data blockvpc_id=data.aws_vpc.main_vpc.id}QuickstartYou can install InfraGenie CLI via pippipinstallinfragenieUsageYou can use the examples to try out infragenie:Clone the repository:git clone https://github.com/diggerhq/infragenie
cd infragenie/examples/ecs_fargateexport your AWS keys:export AWS_ACCESS_KEY_ID=<Access Key>
export AWS_SECRET_ACCESS_KEY=<Secret>Use igm to apply the example:igm applytake note of the generated.infrageniedirectory along with all the generated data. After exploration you can destroy the resources with:igm destroyContributingPull requests are welcome. For major changes, please open an issue first to discuss what you would like to change.Please start the project if you think other people will also find it useful.LicenseMIT
Package: infrared
InfraRed is a plugin based system that aims to provide an easy-to-use CLI for Ansible based projects.
It aims to leverage the power of Ansible in managing / deploying systems, while providing an alternative, fully customized,
CLI experience that can be used by anyone, without prior Ansible knowledge.The project originated from Red Hat OpenStack infrastructure team that looked for a solution to provide an “easier” method
for installing OpenStack from CLI but has since grown and can be used foranyAnsible based projects.Want to take it for a spin? check out our docs at the bottom under theOfficial Documentation.How to contribute?To contribute please follow:http://infrared.readthedocs.io/en/latest/contribute.htmlOfficial DocumentationFor more information Please read ourDocumentation
Package: infrared-V3
InfraRed is a plugin based system that aims to provide an easy-to-use CLI for Ansible based projects.
It aims to leverage the power of Ansible in managing / deploying systems, while providing an alternative, fully customized,
CLI experience that can be used by anyone, without prior Ansible knowledge.The project originated from Red Hat OpenStack infrastructure team that looked for a solution to provide an “easier” method
for installing OpenStack from CLI but has since grown and can be used foranyAnsible based projects.Want to take it for a spin? check out our docs at the bottom under theOfficial Documentation.How to contribute?To contribute please follow:http://infrared.readthedocs.io/en/latest/contribute.htmlOfficial DocumentationFor more information Please read ourDocumentation
Package: infrascope
infrascope closes the feedback loop for data generated by yourInfrastructure as Code, and delivery pipelines. It generates
visibility for the  actual state of your deployments, like versions
of artifacts in your repositories and runtime environments.For more, read the manual athttp://1and1.github.io/infrascope/.Copyright © 2013 1&1 Internet AGLicensed under the Apache License, Version 2.0