Igor,
All examples are in 'ignite/modules/platforms/python/examples'.
I put examples in separate Python files mostly to be able to
automatically confirm their operability. All the lengthy explanations
and cross-references are in the main documentation:
https://apache-ignite-binary-protocol-client.readthedocs.io/en/latest/examples.html
To make it easier for end users to navigate in pyignite directories, I
added a small README file to the 'examples' directory with a short
description and a link to the docs:
https://github.com/nobitlost/ignite/blob/ignite-7782/modules/platforms/python/examples/readme.md
If you think this README is lacking something regardless of the main
pyignite docs, please let me know.
On 9/17/18 8:59 PM, Igor Sapego wrote:
Dmitry,
Sorry, I was not clear enough. What I mean is that Ignite distributed
by both source and binary releases. Binary releases contain platforms
code, which is needed to write your own application in the language,
but does not contain developer stuff, such as tests, documentation
generating scripts, etc.
Of course, it is more common to use package managers when
developing your application, and of course, we are going to support
this approach. But still, we provide a way for a user to get any client
without any package manager.
I like the idea of supplying whl package in a binary release, though it
looks like it's going to take more effort to implement it. But I believe
except for the whl package, we will need to supply examples and
instructions, how user can run them.
What do you think?
Best Regards,
Igor
On Sat, Sep 15, 2018 at 7:03 AM Dmitry Melnichuk <
dmitry.melnic...@nobitlost.com> wrote:
Igor,
I am in doubt here because I am not fully comprehend the meaning of
"binary release". But if it is somehow related to the "distribution"
thing, I would dare to suggest the following options:
1. Copy nothing. Just do
```
$ python setup.py bdist_wheel
$ twine upload dist/*
```
during the build process (or separately) and let PyPI handle the
distribution.
This is the most natural and user-friendly way of distributing Python
packages. End user might only do
```
$ pip install pyignite
```
as it is suggested by my readme file.
2. Supply the wheel package. It is the file 'pyignite-*.whl' from 'dist'
directory, that should appear there as the "python setup.py bdist_wheel"
command finishes. Actually, it can be combined with the first option.
The wheel can then be installed by the end user:
```
$ pip install pyignite-*.whl
```
3. Supply the following files:
ignite/modules/platforms/python/pyignite/**
ignite/modules/platforms/python/requirements/**
ignite/modules/platforms/python/LICENSE
ignite/modules/platforms/python/README.md
ignite/modules/platforms/python/setup.py
(** stands for "all the files and sub-folders recursively, starting from
this folder".)
It is not uncommon or wrong to distribute Python programs as text
without prior packaging, but, in my personal experience, this is a way
more suitable for one-time scripts or proprietary programs. For example,
most of Python web apps relies on git for deployment, without any
packaging subsystem.
Here's a few words about wheels:
https://wheel.readthedocs.io/
Here's about uploading to PyPI with twine:
https://packaging.python.org/tutorials/packaging-projects/#uploading-the-distribution-archives
On 9/14/18 9:05 PM, Igor Sapego wrote:
Ok, good.
Now, what is about installation? Which directories/files
need to be copied to ignite's binary release?
Best Regards,
Igor
