# `xeno`: The Python dependency injector from outer space.
[](https://travis-ci.org/lainproliant/xeno)
`xeno` at its core is a simple Python dependency injection framework. Use it when
you need to manage complex inter-object dependencies in a clean way. For the
merits of dependency injection and IOC, see
https://en.wikipedia.org/wiki/Dependency_injection.
`xeno` should feel pretty familiar to users of Google Guice in Java, as it
is somewhat similar, although it is less focused on type names and more
on named resources and parameter injection.
`xeno` also offers `xeno.build`, a build automation framework built atop the core
dependency injection inspired by [Invoke](https://www.pyinvoke.org/). It is
intended to come with batteries-included tools for making C/C++ projects,
executing shell scripts, batching, and more. It is built on the concept of
composable "recipes", which are generic instructions for building different
types of filesystem targets.
# Installation
Installation is simple. With python3-pip, do the following:
```
$ sudo pip install -e .
```
Or, to install the latest version available on PyPI:
```
$ sudo pip install xeno
```
# Usage
## As a build automation framework
To use `xeno.build` to build a simple C software project, first create a file
called `build.py` in your repo (it can be called anything, but this is
customary). Follow this template example for guidance:
```
#!/usr/bin/env python3
from xeno.build import *
# TODO: Add recipes, providers, and tasks here.
build()
```
Then, you can import the `compile` recipe from `xeno.recipes.c`:
```
from xeno.recipes.c import compile, ENV
```
`ENV` here is the default environment variables that `compile` will use by
default. It defaults to using `clang` to compile C projects, you can change
that here, and you can add additional compile-time flags. The `ENV` object is
of type `xeno.shell.Environment`, which allows for some complex shlex-based
joining and recombining of flags, such that you can additively compose the
enviornment with defaults and/or what may be specified outside the build script.
You can also provide your own environment variables via the `env=` parameter to
`compile`.
```
ENV['CC'] = 'gcc'
ENV += dict(
LDFLAGS='-g'
)
```
Let's create a provider that lists all of our source files and another that
lists our headers. This will be useful for defining our tasks and using the
`compile` recipe.
```
from pathlib import Path
@provide
def source_files():
return Path.cwd().glob("src/*.c")
@provide
def header_files():
return Path.cwd().glob("include/*.h")
```
Next, let's define a single default task that builds our program.
```
@task(default=True)
def executable(source_files, header_files):
return compile(source_files, target="my_program", headers=header_files)
```
`compile` can take iterables of source files and/or combinations of strings and
lists in `*args`. In this case, we elected to specify a target name for the
program. If this wasn't the case, the name of the resulting target would be
based on the name of the first source file. This is ideal if there is only one
source being provided or if the main source file is always provided first and is
the desired name of the executable, but in this case it would be whatever came
first in the directory order which isn't deterministic or ideal.
Specifying the `headers=` parameter here links the recipe to our header files
as static file dependencies. If these files change, the recipe is acknowledged
to be `outdated`, and will be rebuilt the next time the build script is run even
if an executable target already exists.
That's it! Let's put it all together, and then we'll have a build script for
our program.
```
#!/usr/bin/env python3
from xeno.build import *
from xeno.recipes.c import compile, ENV
from pathlib import Path
ENV['CC'] = 'gcc'
ENV += dict(
LDFLAGS='-g'
)
@provide
def source_files():
return Path.cwd().glob("src/*.c")
@provide
def header_files():
return Path.cwd().glob("include/*.h")
build()
```
Mark this script as executable and run it as `./build.py`, or use `python
build.py`. Be sure to check out `./build.py --help` for a list of command line
options and running modes. `xeno.build` is smart and can create addressable
targets from a variety of different nested recipe construction scenarios, so
build more complex scripts and try out `./build.py -L` to see them all!
Watch this space for more in-depth documentation to come in the near future.
## As an IOC framework
To use `xeno` as a dependency injection framework, you need to create a
xeno.Injector and provide it with modules. These modules are regular
Python objects with methods marked with the `@xeno.provider`
annotation. This annotation tells the `Injector` that this method
provides a named resource, the same name as the method marked with
`@provider`. These methods should either take no parameters (other
than `self`), or take named parameters which refer to other resources
by name, i.e. the providers can also be injected with other resources in
order to build a dependency chain.
Once you have an `Injector` full of resources, you can use it to
inject instances, functions, or methods with resources.
To create a new object instance by injecting resources into its
constructor, use `Injector.create(clazz)`, where `clazz` is the
class which you would like to instantiate. The constructor of this class
is called, and all named parameters in the constructor are treated as
resource references. Once the object is instantiated, any methods marked
with `@inject` are invoked with named resources provided.
Resources can be injected into normal functions, bound methods, or
existing object instances via `Injector.inject(obj)`. If the parameter
is an object instance, it is scanned for methods marked with `@inject`
and these methods are invoked with named resources provided.
### Example
In this simple example, we inject an output stream into an object.
```
import sys
from xeno import *
class OutputStreamModule:
@provide
def output_stream(self):
return sys.stdout
class VersionWriter:
def __init__(self, output_stream):
self.output_stream = output_stream
def write_version(self):
print('The python version is %s' % sys.version_info,
file=self.output_stream)
injector = Injector(OutputStreamModule())
writer = injector.create(VersionWriter)
writer.write_version()
```
Checkout `test.py` in the git repo for more usage examples.
## Change Log
### Version 7.3.0: Oct 9 2023
- `xeno.build` targets can now receive arguments! All args after a lone '@' arg are packed into an
implicit `argv` resource that can be injected into targets automatically.
- Fixed broken `run_as` functionality in `ShellRecipe`.
### Version 7.2.2: Oct 7 2023
- Add a `**kwargs` pass-thru for `xeno.shell.check()` for passing args to `subprocess.check_output()`.
### Version 7.2.1: Sep 15 2023
- Allow recipe factories to return empty results as None (or no explicit return value).
### Version 7.2.0: Sep 15 2023
- Improvements to the busy spinner: it now loops through pending recipe sigils
to let the user know what is blocking in the build.
- Improved xeno.recipes.checkout() now opens `build.py` and checks its Python AST
for references to "xeno" before trying to run "./build.py deps" if "build.py"
is present in the resulting repository.
### Version 7.1.0: Sep 09 2023
- Add a `update()` override to `xeno.shell.Environment` which takes
the same arguments as `select()` but updates the dictionary in-place
instead of making and returning a new one.
### Version 7.0.0: Sep 09 2023
- Lift various build recipes from different projects into a
"batteries-included" set of build tools under `xeno.recipes.**`.
- New enriched focus on backwards compatibility between minor versons.
- Restructuring and refactoring, `xeno.cookbook` is deprecated.
- From now on, legacy features will be marked as deprecated and made to
continue to work until the next major version, during which they
will be removed.
### Version 4.12.0: Aug 07 2022
- Changes to support Python 3.10, older versions are now deprecated.
### Version 4.10.0: Oct 28 2021
- Allow recipes to be specified with glob-style wildcards, as per `fnmatch`.
### Version 4.9.0: Jan 03 2021
- Deprecate `@recipe` factory decorator for `@factory`.
- Allow recipes to specify a `setup` recipe, which is not part
of the recipe inputs or outputs but is needed to fulfill the task.
### Version 4.8.0: Dec 29 2020
- All recipe resources are loaded before targets are determined.
- Recipe names are now valid targets for a build.
### Version 4.7.0: Dec 16 2020
- Fixed a bug where build would continue resolving with outdated results.
- Added `@recipe` decorator to `xeno.build` to denote recipe functions.
### Version 4.4.0: Nov 2 2020
- Added experimental `xeno.build` module, a declarative build system driven by IOC.
- Added `xeno.color` offering basic ANSI color and terminal control.
### Version 4.3.0: May 9 2020
- Allow methods to be decorated with `@injector.provide`, eliminating the need for modules
in some simple usage scenarios.
### Version 4.2.0: May 8 2020
- Split `Injector` into `AsyncInjector` and `SyncInjector` to allow injection to be performed
in context of another event loop if async providers are not used.
- Fixed `AsyncInjector` to actually support asynchronous resolution of dependencies.
### Version 4.1.0: Feb 3 2020
- Added `Injector.get_ordered_dependencies` to get a breadth first list of
dependencies in the order they are built.
### Version 4.0.0: May 12 2019
***BACKWARDS INCOMPATIBLE CHANGE***
- Removed support for parameter annotation aliases. Use `@alias` on methods instead.
This was removed to allow `xeno` code to play nicely with PEP 484 type hinting.
### Version 3.1.0: August 29 2018
- Add ClassAttributes.for_object convenience method
### Version 3.0.0: May 4 2018
***BACKWARDS INCOMPATIBLE CHANGE***
- Provide injection interceptors with an alias map for the given param map.
- This change breaks all existing injection interceptors until the new param is added.
### Version 2.8.0: May 3 2018
- Allow decorated/wrapped methods to be properly injected if their `'params'` method attribute
is carried forward.
### Version 2.7.0: April 20 2018
- The `Injector` now adds a `'resource-name'` attribute to resource methods allowing
the inspection of a resource's full canonical name at runtime.
### Version 2.6.0: March 27 2018
- Bugfix release: Remove support for implicit asynchronous resolution of
dependencies. Providers can still be async, in order to await some other
set of coroutines, but can no longer themselves be run in sync. The
benefits do not outweigh the complexity of bugs and timing concerns
introduced by this approach.
### Version 2.5.0: March 2, 2018
- Added `Injector.provide_async()`. Note that resource are always run within an
event loop and should not use `inject()`, `provide()`, or `require()`
directly, instead they should use `inject_async()`, `provide_async()`, and
`require_async()` to dynamically modify resources.
### Version 2.4.1: January 30, 2018
- Added `Injector.scan_resources()` to allow users to scan for resource names with the given attributes.
- Added `Attributes.merge()` to assist with passing attributes down to functions which are wrapped in a decorator.
- Added `MethodAttributes.wraps()` static decorator to summarize a common use case of attribute merging.
- Added `MethodAttributes.add()` as a simple static decorator to add attribute values to a method's attributes.
### Version 2.4.0: January 21, 2018
- Dropped support for deprecated `Namespace.enumerate()` in favor of `Namespace.get_leaves()`.
### Version 2.3.0: January 21, 2018
- Added support for asyncio-based concurrency and async provider coroutines with per-injector event loops (`injector.loop`).
### Version 2.2.0: September 19, 2017
- Expose the Injector's Namespace object via `Injector.get_namespace()`. This is useful for users who want to list the contents of namespaces.
### Version 2.1.0: August 23rd, 2017
- Allow multiple resource names to be provided to `Injector.get_dependency_graph()`.
### Version 2.0.0: July 25th, 2017
***BACKWARDS INCOMPATIBLE CHANGE***
- Change the default namespace separator and breakout symbol to '/'
Code using the old namespace separator can be made to work by overriding the value of xeno.Namespace.SEP:
```
import xeno
xeno.Namespace.SEP = '::'
```
### Version 1.10: July 25th, 2017
- Allow names prefixed with `::` to escape their module's namespace, e.g. `::top_level_item`
### Version 1.9: May 23rd, 2017
- Add `@const()` module annotation for value-based resources
- Add `Injector.get_dependency_tree()` to fetch a tree of dependency names for a given resource name.
### Version 1.8: May 16th, 2017
- Add `MissingResourceError` and `MissingDependencyError` exception types.
### Version 1.7: May 16th, 2017
- Major update, adding support for namespaces, aliases, and inline resource parameter aliases. See the unit tests in test.py for examples.
- Added `@namespace('Name')` decorator for modules to specify that all resources defined in the module should be scoped within 'Name::'.
- Added `@name('alt-name')` to allow resources to be named something other than the name of the function that defines them.
- Added `@alias('alt-name', 'name')` to allow a resource to be renamed within either the scope of a single resource or a whole module.
- Added `@using('NamespaceName')` to allow the contents of the given namespace
to be automatically aliases into either the scope of a single resource or
a whole module.
- Added support for resource function annotations via PEP 3107 to allow
inline aliases, e.g. `def my_resource(name: 'Name::something-important'):`
### Version 1.6: April 26th, 2017
- Changed how `xeno.MethodAttributes` works: it now holds a map of attributes
and provides methods `get()`, `put()`, and `check()`
### Version 1.5: April 26th, 2017
- Added injection interceptors
- Refactored method tagging to use `xeno.MethodAttributes` instead of named
object attributes to make attribute tagging more flexible and usable by
the outside world, e.g. for the new injectors.
### Version 1.4: August 30th, 2016
- Added cycle detection.
### Version 1.3: August 29th, 2016
- Have the injector offer itself as a named resource named 'injector'.
Raw data
{
"_id": null,
"home_page": "https://github.com/lainproliant/xeno",
"name": "xeno",
"maintainer": "",
"docs_url": null,
"requires_python": "",
"maintainer_email": "",
"keywords": "IOC dependency injector build system",
"author": "Lain Musgrove (lainproliant)",
"author_email": "lainproliant@gmail.com",
"download_url": "https://files.pythonhosted.org/packages/0a/5b/394e0a9cde346fda072d9caa105e04541d7d5b47966b0175645d02b51b89/xeno-7.8.1.tar.gz",
"platform": null,
"description": "# `xeno`: The Python dependency injector from outer space. \n[](https://travis-ci.org/lainproliant/xeno)\n\n`xeno` at its core is a simple Python dependency injection framework. Use it when\nyou need to manage complex inter-object dependencies in a clean way. For the\nmerits of dependency injection and IOC, see\nhttps://en.wikipedia.org/wiki/Dependency_injection.\n\n`xeno` should feel pretty familiar to users of Google Guice in Java, as it\nis somewhat similar, although it is less focused on type names and more\non named resources and parameter injection.\n\n`xeno` also offers `xeno.build`, a build automation framework built atop the core\ndependency injection inspired by [Invoke](https://www.pyinvoke.org/). It is\nintended to come with batteries-included tools for making C/C++ projects,\nexecuting shell scripts, batching, and more. It is built on the concept of\ncomposable \"recipes\", which are generic instructions for building different\ntypes of filesystem targets.\n\n\n# Installation\n\nInstallation is simple. With python3-pip, do the following:\n\n```\n$ sudo pip install -e .\n```\n\nOr, to install the latest version available on PyPI:\n\n```\n$ sudo pip install xeno\n```\n\n# Usage\n## As a build automation framework\n\nTo use `xeno.build` to build a simple C software project, first create a file\ncalled `build.py` in your repo (it can be called anything, but this is\ncustomary). Follow this template example for guidance:\n\n```\n#!/usr/bin/env python3\nfrom xeno.build import *\n\n# TODO: Add recipes, providers, and tasks here.\n\nbuild()\n```\n\nThen, you can import the `compile` recipe from `xeno.recipes.c`:\n\n```\nfrom xeno.recipes.c import compile, ENV\n```\n\n`ENV` here is the default environment variables that `compile` will use by\ndefault. It defaults to using `clang` to compile C projects, you can change\nthat here, and you can add additional compile-time flags. The `ENV` object is\nof type `xeno.shell.Environment`, which allows for some complex shlex-based\njoining and recombining of flags, such that you can additively compose the\nenviornment with defaults and/or what may be specified outside the build script.\nYou can also provide your own environment variables via the `env=` parameter to\n`compile`.\n\n```\nENV['CC'] = 'gcc'\nENV += dict(\n LDFLAGS='-g'\n)\n```\n\nLet's create a provider that lists all of our source files and another that\nlists our headers. This will be useful for defining our tasks and using the\n`compile` recipe.\n\n```\nfrom pathlib import Path\n\n@provide\ndef source_files():\n return Path.cwd().glob(\"src/*.c\")\n\n@provide\ndef header_files():\n return Path.cwd().glob(\"include/*.h\")\n```\n\nNext, let's define a single default task that builds our program.\n\n```\n@task(default=True)\ndef executable(source_files, header_files):\n return compile(source_files, target=\"my_program\", headers=header_files)\n```\n\n`compile` can take iterables of source files and/or combinations of strings and\nlists in `*args`. In this case, we elected to specify a target name for the\nprogram. If this wasn't the case, the name of the resulting target would be\nbased on the name of the first source file. This is ideal if there is only one\nsource being provided or if the main source file is always provided first and is\nthe desired name of the executable, but in this case it would be whatever came\nfirst in the directory order which isn't deterministic or ideal.\n\nSpecifying the `headers=` parameter here links the recipe to our header files\nas static file dependencies. If these files change, the recipe is acknowledged\nto be `outdated`, and will be rebuilt the next time the build script is run even\nif an executable target already exists.\n\nThat's it! Let's put it all together, and then we'll have a build script for\nour program.\n\n```\n#!/usr/bin/env python3\nfrom xeno.build import *\nfrom xeno.recipes.c import compile, ENV\nfrom pathlib import Path\n\nENV['CC'] = 'gcc'\nENV += dict(\n LDFLAGS='-g'\n)\n\n@provide\ndef source_files():\n return Path.cwd().glob(\"src/*.c\")\n\n@provide\ndef header_files():\n return Path.cwd().glob(\"include/*.h\")\n\nbuild()\n```\n\nMark this script as executable and run it as `./build.py`, or use `python\nbuild.py`. Be sure to check out `./build.py --help` for a list of command line\noptions and running modes. `xeno.build` is smart and can create addressable\ntargets from a variety of different nested recipe construction scenarios, so\nbuild more complex scripts and try out `./build.py -L` to see them all!\n\nWatch this space for more in-depth documentation to come in the near future.\n\n## As an IOC framework\n\nTo use `xeno` as a dependency injection framework, you need to create a\nxeno.Injector and provide it with modules. These modules are regular\nPython objects with methods marked with the `@xeno.provider`\nannotation. This annotation tells the `Injector` that this method\nprovides a named resource, the same name as the method marked with\n`@provider`. These methods should either take no parameters (other\nthan `self`), or take named parameters which refer to other resources\nby name, i.e. the providers can also be injected with other resources in\norder to build a dependency chain.\n\nOnce you have an `Injector` full of resources, you can use it to\ninject instances, functions, or methods with resources.\n\nTo create a new object instance by injecting resources into its\nconstructor, use `Injector.create(clazz)`, where `clazz` is the\nclass which you would like to instantiate. The constructor of this class\nis called, and all named parameters in the constructor are treated as\nresource references. Once the object is instantiated, any methods marked\nwith `@inject` are invoked with named resources provided.\n\nResources can be injected into normal functions, bound methods, or\nexisting object instances via `Injector.inject(obj)`. If the parameter\nis an object instance, it is scanned for methods marked with `@inject`\nand these methods are invoked with named resources provided.\n\n### Example\n\nIn this simple example, we inject an output stream into an object.\n\n```\nimport sys\nfrom xeno import *\n\nclass OutputStreamModule:\n @provide\n def output_stream(self):\n return sys.stdout\n\nclass VersionWriter:\n def __init__(self, output_stream):\n self.output_stream = output_stream\n\n def write_version(self):\n print('The python version is %s' % sys.version_info,\n file=self.output_stream)\n\ninjector = Injector(OutputStreamModule())\nwriter = injector.create(VersionWriter)\nwriter.write_version()\n```\n\nCheckout `test.py` in the git repo for more usage examples.\n\n## Change Log\n\n### Version 7.3.0: Oct 9 2023\n- `xeno.build` targets can now receive arguments! All args after a lone '@' arg are packed into an\n implicit `argv` resource that can be injected into targets automatically.\n- Fixed broken `run_as` functionality in `ShellRecipe`.\n\n### Version 7.2.2: Oct 7 2023\n- Add a `**kwargs` pass-thru for `xeno.shell.check()` for passing args to `subprocess.check_output()`.\n\n### Version 7.2.1: Sep 15 2023\n- Allow recipe factories to return empty results as None (or no explicit return value).\n\n### Version 7.2.0: Sep 15 2023\n- Improvements to the busy spinner: it now loops through pending recipe sigils\n to let the user know what is blocking in the build.\n- Improved xeno.recipes.checkout() now opens `build.py` and checks its Python AST\n for references to \"xeno\" before trying to run \"./build.py deps\" if \"build.py\"\n is present in the resulting repository.\n\n### Version 7.1.0: Sep 09 2023\n- Add a `update()` override to `xeno.shell.Environment` which takes\n the same arguments as `select()` but updates the dictionary in-place\n instead of making and returning a new one.\n\n### Version 7.0.0: Sep 09 2023\n- Lift various build recipes from different projects into a\n \"batteries-included\" set of build tools under `xeno.recipes.**`.\n- New enriched focus on backwards compatibility between minor versons.\n- Restructuring and refactoring, `xeno.cookbook` is deprecated.\n- From now on, legacy features will be marked as deprecated and made to\n continue to work until the next major version, during which they\n will be removed.\n\n### Version 4.12.0: Aug 07 2022\n- Changes to support Python 3.10, older versions are now deprecated.\n\n### Version 4.10.0: Oct 28 2021\n- Allow recipes to be specified with glob-style wildcards, as per `fnmatch`.\n\n### Version 4.9.0: Jan 03 2021\n- Deprecate `@recipe` factory decorator for `@factory`.\n- Allow recipes to specify a `setup` recipe, which is not part\n of the recipe inputs or outputs but is needed to fulfill the task.\n\n### Version 4.8.0: Dec 29 2020\n- All recipe resources are loaded before targets are determined.\n- Recipe names are now valid targets for a build.\n\n### Version 4.7.0: Dec 16 2020\n- Fixed a bug where build would continue resolving with outdated results.\n- Added `@recipe` decorator to `xeno.build` to denote recipe functions.\n\n### Version 4.4.0: Nov 2 2020\n- Added experimental `xeno.build` module, a declarative build system driven by IOC.\n- Added `xeno.color` offering basic ANSI color and terminal control.\n\n### Version 4.3.0: May 9 2020\n- Allow methods to be decorated with `@injector.provide`, eliminating the need for modules\n in some simple usage scenarios.\n\n### Version 4.2.0: May 8 2020\n- Split `Injector` into `AsyncInjector` and `SyncInjector` to allow injection to be performed\n in context of another event loop if async providers are not used.\n- Fixed `AsyncInjector` to actually support asynchronous resolution of dependencies.\n\n### Version 4.1.0: Feb 3 2020\n- Added `Injector.get_ordered_dependencies` to get a breadth first list of\n dependencies in the order they are built.\n\n### Version 4.0.0: May 12 2019\n***BACKWARDS INCOMPATIBLE CHANGE***\n- Removed support for parameter annotation aliases. Use `@alias` on methods instead.\n This was removed to allow `xeno` code to play nicely with PEP 484 type hinting.\n\n### Version 3.1.0: August 29 2018\n- Add ClassAttributes.for_object convenience method\n\n### Version 3.0.0: May 4 2018\n***BACKWARDS INCOMPATIBLE CHANGE***\n- Provide injection interceptors with an alias map for the given param map.\n- This change breaks all existing injection interceptors until the new param is added.\n\n### Version 2.8.0: May 3 2018\n- Allow decorated/wrapped methods to be properly injected if their `'params'` method attribute\n is carried forward.\n\n### Version 2.7.0: April 20 2018\n- The `Injector` now adds a `'resource-name'` attribute to resource methods allowing\n the inspection of a resource's full canonical name at runtime.\n\n### Version 2.6.0: March 27 2018\n- Bugfix release: Remove support for implicit asynchronous resolution of\n dependencies. Providers can still be async, in order to await some other\n set of coroutines, but can no longer themselves be run in sync. The\n benefits do not outweigh the complexity of bugs and timing concerns\n introduced by this approach.\n\n### Version 2.5.0: March 2, 2018\n- Added `Injector.provide_async()`. Note that resource are always run within an\n event loop and should not use `inject()`, `provide()`, or `require()`\n directly, instead they should use `inject_async()`, `provide_async()`, and\n `require_async()` to dynamically modify resources.\n\n### Version 2.4.1: January 30, 2018\n- Added `Injector.scan_resources()` to allow users to scan for resource names with the given attributes.\n- Added `Attributes.merge()` to assist with passing attributes down to functions which are wrapped in a decorator.\n- Added `MethodAttributes.wraps()` static decorator to summarize a common use case of attribute merging.\n- Added `MethodAttributes.add()` as a simple static decorator to add attribute values to a method's attributes.\n\n### Version 2.4.0: January 21, 2018\n- Dropped support for deprecated `Namespace.enumerate()` in favor of `Namespace.get_leaves()`.\n\n### Version 2.3.0: January 21, 2018\n- Added support for asyncio-based concurrency and async provider coroutines with per-injector event loops (`injector.loop`).\n\n### Version 2.2.0: September 19, 2017\n- Expose the Injector's Namespace object via `Injector.get_namespace()`. This is useful for users who want to list the contents of namespaces.\n\n### Version 2.1.0: August 23rd, 2017\n- Allow multiple resource names to be provided to `Injector.get_dependency_graph()`.\n\n### Version 2.0.0: July 25th, 2017\n***BACKWARDS INCOMPATIBLE CHANGE***\n- Change the default namespace separator and breakout symbol to '/'\n\nCode using the old namespace separator can be made to work by overriding the value of xeno.Namespace.SEP:\n```\nimport xeno\nxeno.Namespace.SEP = '::'\n```\n\n### Version 1.10: July 25th, 2017\n- Allow names prefixed with `::` to escape their module's namespace, e.g. `::top_level_item`\n\n### Version 1.9: May 23rd, 2017\n- Add `@const()` module annotation for value-based resources\n- Add `Injector.get_dependency_tree()` to fetch a tree of dependency names for a given resource name.\n\n### Version 1.8: May 16th, 2017\n- Add `MissingResourceError` and `MissingDependencyError` exception types.\n\n### Version 1.7: May 16th, 2017\n- Major update, adding support for namespaces, aliases, and inline resource parameter aliases. See the unit tests in test.py for examples.\n - Added `@namespace('Name')` decorator for modules to specify that all resources defined in the module should be scoped within 'Name::'.\n - Added `@name('alt-name')` to allow resources to be named something other than the name of the function that defines them.\n - Added `@alias('alt-name', 'name')` to allow a resource to be renamed within either the scope of a single resource or a whole module.\n - Added `@using('NamespaceName')` to allow the contents of the given namespace\n to be automatically aliases into either the scope of a single resource or\n a whole module.\n - Added support for resource function annotations via PEP 3107 to allow\n inline aliases, e.g. `def my_resource(name: 'Name::something-important'):`\n\n### Version 1.6: April 26th, 2017\n- Changed how `xeno.MethodAttributes` works: it now holds a map of attributes\n and provides methods `get()`, `put()`, and `check()`\n\n### Version 1.5: April 26th, 2017\n- Added injection interceptors\n- Refactored method tagging to use `xeno.MethodAttributes` instead of named\n object attributes to make attribute tagging more flexible and usable by\n the outside world, e.g. for the new injectors.\n\n### Version 1.4: August 30th, 2016\n- Added cycle detection.\n\n### Version 1.3: August 29th, 2016\n- Have the injector offer itself as a named resource named 'injector'.\n\n",
"bugtrack_url": null,
"license": "BSD",
"summary": "The Python IOC app and build framework from outer space.",
"version": "7.8.1",
"project_urls": {
"Homepage": "https://github.com/lainproliant/xeno"
},
"split_keywords": [
"ioc",
"dependency",
"injector",
"build",
"system"
],
"urls": [
{
"comment_text": "",
"digests": {
"blake2b_256": "0a5b394e0a9cde346fda072d9caa105e04541d7d5b47966b0175645d02b51b89",
"md5": "d19525e60effd131a567bd670f71de40",
"sha256": "d8127f1799b5653b503e55e996e1178ba3e4d0dde0a1915fc3c8fd6f431814f3"
},
"downloads": -1,
"filename": "xeno-7.8.1.tar.gz",
"has_sig": false,
"md5_digest": "d19525e60effd131a567bd670f71de40",
"packagetype": "sdist",
"python_version": "source",
"requires_python": null,
"size": 46595,
"upload_time": "2024-03-17T06:26:44",
"upload_time_iso_8601": "2024-03-17T06:26:44.416417Z",
"url": "https://files.pythonhosted.org/packages/0a/5b/394e0a9cde346fda072d9caa105e04541d7d5b47966b0175645d02b51b89/xeno-7.8.1.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2024-03-17 06:26:44",
"github": true,
"gitlab": false,
"bitbucket": false,
"codeberg": false,
"github_user": "lainproliant",
"github_project": "xeno",
"travis_ci": true,
"coveralls": false,
"github_actions": false,
"lcname": "xeno"
}
JSON
