|
8 | 8 | - [User provided arguments](#user-provided-arguments)
|
9 | 9 | - [Data input](#data-input)
|
10 | 10 | - [Deattaching data from its original source](#deattaching-data-from-its-original-source)
|
11 |
| - - [Custom ad-hoc plugins](#custom-ad-hoc-plugins) |
12 | 11 | - [Run tests](#run-tests)
|
13 | 12 | - [Build documentation](#build-documentation)
|
| 13 | + - [Improve plugin documentation](#improve-plugin-documentation) |
| 14 | +- [Make your plugin project available](#make-your-plugin-project-available) |
14 | 15 |
|
15 | 16 | ## Creating a new plugin
|
16 | 17 |
|
@@ -385,7 +386,7 @@ The core of `webviz-config` will do the following:
|
385 | 386 | 2) If the user asks for a portable version, it will
|
386 | 387 | 1) Before writing the actual dash code, it will run all decorated functions
|
387 | 388 | with the given argument combinations. The resulting dataframes are stored
|
388 |
| - in a folder `./webviz_storage` as parquet files. |
| 389 | + in a folder `./resources/webviz_storage` as parquet files. |
389 | 390 | 2) It writes the webviz-dash code (as usual), but this the decorated
|
390 | 391 | functions will return the dataframe from the stored `.parquet` files,
|
391 | 392 | instead of running the actual function code.
|
@@ -457,58 +458,6 @@ signature is not necessary, however if you do you will get a
|
457 | 458 | instance representing the absolute path to the configuration file that was used, and/or
|
458 | 459 | a boolean value stating if the Webviz application running is a portable one.
|
459 | 460 |
|
460 |
| -### Custom ad-hoc plugins |
461 |
| - |
462 |
| -It is possible to create custom plugins which still can be included through |
463 |
| -the configuration file, which could be useful for quick prototyping. |
464 |
| - |
465 |
| -As an example, assume someone on your project has made the Python file |
466 |
| - |
467 |
| -```python |
468 |
| -import dash_html_components as html |
469 |
| -from webviz_config import WebvizPluginABC |
470 |
| - |
471 |
| - |
472 |
| -class OurCustomPlugin(WebvizPluginABC): |
473 |
| - |
474 |
| - def __init__(self, title: str): |
475 |
| - |
476 |
| - super().__init__() |
477 |
| - |
478 |
| - self.title = title |
479 |
| - |
480 |
| - @property |
481 |
| - def layout(self): |
482 |
| - return html.Div([ |
483 |
| - html.H1(self.title), |
484 |
| - 'This is just some ordinary text' |
485 |
| - ]) |
486 |
| -``` |
487 |
| - |
488 |
| -If this is saved such that it is available through e.g. a |
489 |
| -[module](https://docs.python.org/3/tutorial/modules.html) |
490 |
| -`ourmodule`, the user can include the custom plugin the same way as a standard |
491 |
| -plugin, with the only change of also naming the module: |
492 |
| -```yaml |
493 |
| -title: Simple Webviz example |
494 |
| - |
495 |
| -pages: |
496 |
| - |
497 |
| - - title: Front page |
498 |
| - content: |
499 |
| - - ourmodule.OurCustomPlugin: |
500 |
| - title: Title of my custom plugin |
501 |
| -``` |
502 |
| -
|
503 |
| -Note that this might involve appending your `$PYTHONPATH` environment |
504 |
| -variable with the path where your custom module is located. The same principle |
505 |
| -applies if the custom plugin is saved in a package with submodule(s), |
506 |
| -```yaml |
507 |
| - ... |
508 |
| - - ourpackage.ourmodule.OurCustomPlugin: |
509 |
| - ... |
510 |
| -``` |
511 |
| - |
512 | 461 | ## Run tests
|
513 | 462 |
|
514 | 463 | To run tests it is necessary to first install the [selenium chrome driver](https://github.com/SeleniumHQ/selenium/wiki/ChromeDriver).
|
@@ -584,3 +533,39 @@ $$\alpha = \frac{\beta}{\gamma}$$
|
584 | 533 |
|
585 | 534 | Example of auto-built documentation for `webviz-config` can be seen
|
586 | 535 | [here on github](https://equinor.github.io/webviz-config/).
|
| 536 | + |
| 537 | +## Make your plugin project available |
| 538 | + |
| 539 | +It is strongly recommended to store your plugin project code base in a `git` solution, |
| 540 | +e.g. [in a new GitHub repository](https://github.com/new). If possible, it is also |
| 541 | +_highly_ recommended to let it be an open source repository. This has several advantages: |
| 542 | + - Others can reuse your work - and help each other achieve better code quality, add more features and share maintenance |
| 543 | + - You will from the beginning make sure you keep a good separation between visualization code and data loading/processing code. |
| 544 | + - It becomes easier for your plugin users to use it in e.g. Docker and in cloud hosting. |
| 545 | + |
| 546 | +`webviz-config` will make sure that portable builds, which uses one (or more) plugins |
| 547 | +from your plugin project, includes installation instructions for the project also in |
| 548 | +the Docker build instructions. In order for `webviz-config` to do this, you should add |
| 549 | +[`project_urls` metadata](https://packaging.python.org/guides/distributing-packages-using-setuptools/#project-urls) |
| 550 | +in the project's `setup.py`. An example: |
| 551 | +``` |
| 552 | + project_urls={ |
| 553 | + "Download": "https://pypi.org/project/webviz-config", |
| 554 | + "Source": "https://github.com/equinor/webviz-config", |
| 555 | + }, |
| 556 | +``` |
| 557 | +The following logic applies when the user creates a portable application: |
| 558 | +- If `Download` is specified *and* the plugin project version installed is available |
| 559 | + on PyPI, the Dockerfile will `pip install` the same version from PyPI. |
| 560 | +- Otherwise the Dockerfile will install from the `Source` url. From the `setuptools_scm` |
| 561 | + provided version, the correct commit/version/tag will be installed. |
| 562 | + |
| 563 | +Note that if you are a developer and working on a fork, you might want to temporarily |
| 564 | +override the `Source` url to your fork. You can do this by specifying an environment |
| 565 | +variable `SOURCE_URL_NAME_PLUGIN_PROJECT=https://urlyourfork`. If you also want to |
| 566 | +explicitly state git pointer/reference (thereby not use the one derived from |
| 567 | +`setuptools_scm` version) you can set the environment variable |
| 568 | +`GIT_POINTER_NAME_PLUGIN_PROJECT`. |
| 569 | + |
| 570 | +For private repositories, a GitHub SSH deploy key will need to be provided to the Docker |
| 571 | +build process (see instructions in `README` created with the portable application). |
0 commit comments