# -*- coding: utf-8 -*-
from setuptools import setup

package_dir = \
{'': 'src'}

packages = \
['polugins']

package_data = \
{'': ['*']}

install_requires = \
['importlib-metadata>=6.6.0,<7.0.0',
 'mypy>=1.3.0,<2.0.0',
 'polars>=0.18.0,<0.19.0']

setup_kwargs = {
    'name': 'polugins',
    'version': '0.2.0',
    'description': 'Plugin system for Polars.',
    'long_description': '# Polugins\n\nEarly PoC for a "plugin" system for polars.\n\nNot production ready - barely even alpha ready. Only uploading it now for discussion and to hog the genius package name.\n\nIt\'s meant to solve two issues with using polars API extensions:\n\n- You need to import the namespace to trigger the registration, even if you dont need anything from the namespace module.\n\n- Extensions breaks static typing.\n\nThe idea is to describe a single way to expose and collect API extensions - especially for third party packages - \nand then used this discoverbility to also generate type stubs with the added typing from the extensions.\n\nUsers can either call `register_namespaces` themselves or import polars through `polugins.polars` instead.\nLint rules can then be used to enforce that nothing is imported from polars outside of these locations.\n\nThis is still a bit annoying no matter what, unless polars does the import natively.\n\n## Package example\n\nPackages can expose namespace through entry points called `polugins.<class>`, forexample `polugins.lazyframe`.\n\nIf building with poetry you should add this to your `pyproject.toml`:\n\n```toml\n[tool.poetry.plugins."polugins.<class>"]\n"<accessor_name>" = "<path.to.module:NameSpace>"\n\n# Concrete example:\n\n[tool.poetry.plugins."polugins.lazyframe"]\n"external" = "example_package:PackageNamespace"\n```\n\nSee `tests/pkgs/example_package` for a example.\n\n## Usage example\n\nNamespaces can be registered in three ways:\n\n- By module path\n- As imported module\n- From entry points\n\nSay that you have a package `my_package` with two `LazyFrame` namespaces - `MyNamespace` and `AlsoMyNamespace` and you use an\nexternal package `example-package` that exposes a `LazyFrame` namespace called `external`.\nAfter installing it, namespaces can be registered like so:\n\n```python\nfrom polugins import register_namespaces\nimport polars as pl\nfrom my_package import MyNamespace\n\nregister_namespaces(\n    lazyframe_namespaces={\n        \'my_namespace\': MyNamespace,\n        \'also_my_namespace\': "my_package:AlsoMyNamespace" # Note the `:` to separate module path from object\n    },\n    entrypoints=True # Loads from example-package\n  )\n\n# All namespaces are now registered\n(\n  pl.LazyFrame()\n  .external.some_method()\n  .my_namespace.some_method()\n  .also_my_namespace.some_method()\n)\n```\n\nYou need to make sure that you have called `register_namespaces` before trying to use any of those namespaces.\n\nAs an alternative, polars is re-exported through `polugins` such that entrypoint namespaces are automagically registered:\n\n```python\nfrom polugins import pl\n\npl.LazyFrame().external.some_method(x=1)\n```\n\nNote that this only registers entrypoint namespaces (for now).\n\n### Generate types\n\nRun `polugins.create_types.py` to create type stubs. Will create the directory `.typings`.\n\nOnly works for entrypoint namespaces. You can add your own namespaces to the types if you want.\nIt\'s fairly straight forward, just import the namespace on top of the `pyi` and then add an annotation\nto the class with the namespace.\n\nWill be a CLI tool at some point.\n\n## Implementation\n\nJust a thin wrapper around `polars.api.register_x_namespace` and then using `importlib.metadata` to collect\nnamespaces from external packages.\n\nTypes are generated by using mypy to create stubs for lazyframe, dataframe, expr and series and then adding the\nnamespaces to these type stubs.\n\n## Notes\n\nIt\'s still not entirely clear how an application should register its own namespaces.\nEntry points can be used but\n\n- (1) an application might just want to use its own namespaces and not expose them and \n- (2) its a bit annoying, because changes to entrypoints are only registered when the package is installed, even in editable mode (I think).\n\n\n\n',
    'author': 'StefanBRas',
    'author_email': 'opensource@bruhn.io',
    'maintainer': 'None',
    'maintainer_email': 'None',
    'url': 'None',
    'package_dir': package_dir,
    'packages': packages,
    'package_data': package_data,
    'install_requires': install_requires,
    'python_requires': '>=3.8,<4.0',
}


setup(**setup_kwargs)
