Python thin client

[Dmitry Melnichuk]

Hello, Igniters!

Please review my work on Ignite thin client library written in Python 3.

Pull request:
https://github.com/apache/ignite/pull/4278

Jira issue with initial proposal:
https://issues.apache.org/jira/browse/IGNITE-7782

The documentation is temporarily available at:
https://apache-ignite-binary-protocol-client.readthedocs.io/

It covers installation, requirements, API specification, coding
examples, instructions on how to run tests and build the documentation
itself.

Dmitry

[Nikolay Izhikov-2]

Hello, Dmitry.

I tried to build your lib locally and it failed.
Error message and pip version are below.

Seems, we have to fix developer instructions.
Do we need specific version of pip or something?
I tried to use default versions.
I using Ubuntu Linux.

dragon:~/src/ignite/modules/platforms/python:[IGNITE-7782]$ pip install -v -e .
Obtaining file:///home/dragon/src/ignite/modules/platforms/python
  Running setup.py (path:/home/dragon/src/ignite/modules/platforms/python/setup.py) egg_info for package from file:///home/dragon/src/ignite/modules/platforms/python
    Running command python setup.py egg_info
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/home/dragon/src/ignite/modules/platforms/python/setup.py", line 20
        def is_a_requirement(line: str) -> bool:
                                 ^
    SyntaxError: invalid syntax
Cleaning up...
Command "python setup.py egg_info" failed with error code 1 in /home/dragon/src/ignite/modules/platforms/python/
Exception information:
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/pip/basecommand.py", line 215, in main
    status = self.run(options, args)
  File "/usr/lib/python2.7/dist-packages/pip/commands/install.py", line 353, in run
    wb.build(autobuilding=True)
  File "/usr/lib/python2.7/dist-packages/pip/wheel.py", line 749, in build
    self.requirement_set.prepare_files(self.finder)
  File "/usr/lib/python2.7/dist-packages/pip/req/req_set.py", line 380, in prepare_files
    ignore_dependencies=self.ignore_dependencies))
  File "/usr/lib/python2.7/dist-packages/pip/req/req_set.py", line 518, in _prepare_file
    abstract_dist.prep_for_dist()
  File "/usr/lib/python2.7/dist-packages/pip/req/req_set.py", line 129, in prep_for_dist
    self.req_to_install.run_egg_info()
  File "/usr/lib/python2.7/dist-packages/pip/req/req_install.py", line 439, in run_egg_info
    command_desc='python setup.py egg_info')
  File "/usr/lib/python2.7/dist-packages/pip/utils/__init__.py", line 725, in call_subprocess
    % (command_desc, proc.returncode, cwd))
InstallationError: Command "python setup.py egg_info" failed with error code 1 in /home/dragon/src/ignite/modules/platforms/python/
dragon:~/src/ignite/modules/platforms/python:[IGNITE-7782]$ apt-cache policy python-pip
python-pip:
  Установлен: 9.0.1-2.3~ubuntu1
  Кандидат:   9.0.1-2.3~ubuntu1
  Таблица версий:
 *** 9.0.1-2.3~ubuntu1 500
        500 http://ru.archive.ubuntu.com/ubuntu bionic-updates/universe amd64 Packages
        500 http://ru.archive.ubuntu.com/ubuntu bionic-updates/universe i386 Packages
        100 /var/lib/dpkg/status
     9.0.1-2 500
        500 http://ru.archive.ubuntu.com/ubuntu bionic/universe amd64 Packages
        500 http://ru.archive.ubuntu.com/ubuntu bionic/universe i386 Packages
dragon:~/src/ignite/modules/platforms/python:[IGNITE-7782]$ uname -a
Linux newDragon 4.15.0-33-generic #36-Ubuntu SMP Wed Aug 15 16:00:05 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

В Пн, 03/09/2018 в 16:10 +1000, Dmitry Melnichuk пишет:

> Hello, Igniters!
>
> Please review my work on Ignite thin client library written in Python 3.
>
> Pull request:
> https://github.com/apache/ignite/pull/4278
>
> Jira issue with initial proposal:
> https://issues.apache.org/jira/browse/IGNITE-7782
>
> The documentation is temporarily available at:
> https://apache-ignite-binary-protocol-client.readthedocs.io/
>
> It covers installation, requirements, API specification, coding
> examples, instructions on how to run tests and build the documentation
> itself.
>
> Dmitry

[Dmitry Melnichuk]

Hello, Nikolay!

Thank you for your interest in Python thin client.

The traceback suggests that you using Python 2.7. Unfortunately, my
client supports only Python versions 3.4 and later.

Since you are using the latest Ubuntu OS, chances are you already have a
recent Python 3 installed. Try `pip3`.

On 9/3/18 4:25 PM, Nikolay Izhikov wrote:

> Hello, Dmitry.
>
> I tried to build your lib locally and it failed.
> Error message and pip version are below.
>
> Seems, we have to fix developer instructions.
> Do we need specific version of pip or something?
> I tried to use default versions.
> I using Ubuntu Linux.
>
> dragon:~/src/ignite/modules/platforms/python:[IGNITE-7782]$ pip install -v -e .
> Obtaining file:///home/dragon/src/ignite/modules/platforms/python
>    Running setup.py (path:/home/dragon/src/ignite/modules/platforms/python/setup.py) egg_info for package from file:///home/dragon/src/ignite/modules/platforms/python
>      Running command python setup.py egg_info
>      Traceback (most recent call last):
>        File "<string>", line 1, in <module>
>        File "/home/dragon/src/ignite/modules/platforms/python/setup.py", line 20
>          def is_a_requirement(line: str) -> bool:
>                                   ^
>      SyntaxError: invalid syntax
> Cleaning up...
> Command "python setup.py egg_info" failed with error code 1 in /home/dragon/src/ignite/modules/platforms/python/
> Exception information:
> Traceback (most recent call last):
>    File "/usr/lib/python2.7/dist-packages/pip/basecommand.py", line 215, in main
>      status = self.run(options, args)
>    File "/usr/lib/python2.7/dist-packages/pip/commands/install.py", line 353, in run
>      wb.build(autobuilding=True)
>    File "/usr/lib/python2.7/dist-packages/pip/wheel.py", line 749, in build
>      self.requirement_set.prepare_files(self.finder)
>    File "/usr/lib/python2.7/dist-packages/pip/req/req_set.py", line 380, in prepare_files
>      ignore_dependencies=self.ignore_dependencies))
>    File "/usr/lib/python2.7/dist-packages/pip/req/req_set.py", line 518, in _prepare_file
>      abstract_dist.prep_for_dist()
>    File "/usr/lib/python2.7/dist-packages/pip/req/req_set.py", line 129, in prep_for_dist
>      self.req_to_install.run_egg_info()
>    File "/usr/lib/python2.7/dist-packages/pip/req/req_install.py", line 439, in run_egg_info
>      command_desc='python setup.py egg_info')
>    File "/usr/lib/python2.7/dist-packages/pip/utils/__init__.py", line 725, in call_subprocess
>      % (command_desc, proc.returncode, cwd))
> InstallationError: Command "python setup.py egg_info" failed with error code 1 in /home/dragon/src/ignite/modules/platforms/python/
> dragon:~/src/ignite/modules/platforms/python:[IGNITE-7782]$ apt-cache policy python-pip
> python-pip:
>    Установлен: 9.0.1-2.3~ubuntu1
>    Кандидат:   9.0.1-2.3~ubuntu1
>    Таблица версий:
>   *** 9.0.1-2.3~ubuntu1 500
>          500 http://ru.archive.ubuntu.com/ubuntu bionic-updates/universe amd64 Packages
>          500 http://ru.archive.ubuntu.com/ubuntu bionic-updates/universe i386 Packages
>          100 /var/lib/dpkg/status
>       9.0.1-2 500
>          500 http://ru.archive.ubuntu.com/ubuntu bionic/universe amd64 Packages
>          500 http://ru.archive.ubuntu.com/ubuntu bionic/universe i386 Packages
> dragon:~/src/ignite/modules/platforms/python:[IGNITE-7782]$ uname -a
> Linux newDragon 4.15.0-33-generic #36-Ubuntu SMP Wed Aug 15 16:00:05 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
>

[Nikolay Izhikov-2]

Hello, Dmitry.

I understand that for experienced Python developer it obvious from stack trace I send.

But can we check python version on startup?
And print big fat error message "You are using wrong python version".

From my experience, there are some tickets in Ignite that should be implemented in various thin clients.
It a very trivial changes, but lack of testability makes this task harder then steel.

I think a .Net DEVNOTES are very good example.

Please, be gentle with your fellow contributors and make DEVNOTES as clear as possible.

В Пн, 03/09/2018 в 17:07 +1000, Dmitry Melnichuk пишет:

> Hello, Nikolay!
>
> Thank you for your interest in Python thin client.
>
> The traceback suggests that you using Python 2.7. Unfortunately, my
> client supports only Python versions 3.4 and later.
>
> Since you are using the latest Ubuntu OS, chances are you already have a
> recent Python 3 installed. Try `pip3`.
>
> On 9/3/18 4:25 PM, Nikolay Izhikov wrote:
> > Hello, Dmitry.
> >
> > I tried to build your lib locally and it failed.
> > Error message and pip version are below.
> >
> > Seems, we have to fix developer instructions.
> > Do we need specific version of pip or something?
> > I tried to use default versions.
> > I using Ubuntu Linux.
> >
> > dragon:~/src/ignite/modules/platforms/python:[IGNITE-7782]$ pip install -v -e .
> > Obtaining file:///home/dragon/src/ignite/modules/platforms/python
> >    Running setup.py (path:/home/dragon/src/ignite/modules/platforms/python/setup.py) egg_info for package from file:///home/dragon/src/ignite/modules/platforms/python
> >      Running command python setup.py egg_info
> >      Traceback (most recent call last):
> >        File "<string>", line 1, in <module>
> >        File "/home/dragon/src/ignite/modules/platforms/python/setup.py", line 20
> >          def is_a_requirement(line: str) -> bool:
> >                                   ^
> >      SyntaxError: invalid syntax
> > Cleaning up...
> > Command "python setup.py egg_info" failed with error code 1 in /home/dragon/src/ignite/modules/platforms/python/
> > Exception information:
> > Traceback (most recent call last):
> >    File "/usr/lib/python2.7/dist-packages/pip/basecommand.py", line 215, in main
> >      status = self.run(options, args)
> >    File "/usr/lib/python2.7/dist-packages/pip/commands/install.py", line 353, in run
> >      wb.build(autobuilding=True)
> >    File "/usr/lib/python2.7/dist-packages/pip/wheel.py", line 749, in build
> >      self.requirement_set.prepare_files(self.finder)
> >    File "/usr/lib/python2.7/dist-packages/pip/req/req_set.py", line 380, in prepare_files
> >      ignore_dependencies=self.ignore_dependencies))
> >    File "/usr/lib/python2.7/dist-packages/pip/req/req_set.py", line 518, in _prepare_file
> >      abstract_dist.prep_for_dist()
> >    File "/usr/lib/python2.7/dist-packages/pip/req/req_set.py", line 129, in prep_for_dist
> >      self.req_to_install.run_egg_info()
> >    File "/usr/lib/python2.7/dist-packages/pip/req/req_install.py", line 439, in run_egg_info
> >      command_desc='python setup.py egg_info')
> >    File "/usr/lib/python2.7/dist-packages/pip/utils/__init__.py", line 725, in call_subprocess
> >      % (command_desc, proc.returncode, cwd))
> > InstallationError: Command "python setup.py egg_info" failed with error code 1 in /home/dragon/src/ignite/modules/platforms/python/
> > dragon:~/src/ignite/modules/platforms/python:[IGNITE-7782]$ apt-cache policy python-pip
> > python-pip:
> >    Установлен: 9.0.1-2.3~ubuntu1
> >    Кандидат:   9.0.1-2.3~ubuntu1
> >    Таблица версий:
> >   *** 9.0.1-2.3~ubuntu1 500
> >          500 http://ru.archive.ubuntu.com/ubuntu bionic-updates/universe amd64 Packages
> >          500 http://ru.archive.ubuntu.com/ubuntu bionic-updates/universe i386 Packages
> >          100 /var/lib/dpkg/status
> >       9.0.1-2 500
> >          500 http://ru.archive.ubuntu.com/ubuntu bionic/universe amd64 Packages
> >          500 http://ru.archive.ubuntu.com/ubuntu bionic/universe i386 Packages
> > dragon:~/src/ignite/modules/platforms/python:[IGNITE-7782]$ uname -a
> > Linux newDragon 4.15.0-33-generic #36-Ubuntu SMP Wed Aug 15 16:00:05 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
> >

[Dmitry Melnichuk]

Nikolay,

There is indeed a feature in `setuptools` I just learned about, which
would help in this case (and I believe the case you demonstrated can be
quite typical, thank you for pointing it out). It gives user a clever
message in the end of a stack trace like

 > UnsupportedPythonVersion: pyignite requires Python '>=3.4' but the
 > running Python is 2.7.15

This feature is not 100% bullet-proof, and it will not help users who
will try to install my client other way than with `pip` or `setup.py`.
It will also be less helpful with old versions of `pip` (before 9.0).
However, it should cover most situations.

On 9/4/18 7:15 PM, Nikolay Izhikov wrote:
> Hello, Dmitry.
>
> I understand that for experienced Python developer it obvious from
> stack trace I send.
>
> But can we check python version on startup? And print big fat error
> message "You are using wrong python version".
 >
> From my experience, there are some tickets in Ignite that should be
> implemented in various thin clients. It a very trivial changes, but
> lack of testability makes this task harder then steel.
>
> I think a .Net DEVNOTES are very good example.
>
> Please, be gentle with your fellow contributors and make DEVNOTES as
> clear as possible.

[dsetrakyan]

Dmitriy,

setuptools sounds like an installation step. Does it make sense to add a
check during startup of a client?

D.

On Tue, Sep 4, 2018 at 7:25 AM, Dmitry Melnichuk <
[hidden email]> wrote:

> Nikolay,
>
> There is indeed a feature in `setuptools` I just learned about, which
> would help in this case (and I believe the case you demonstrated can be
> quite typical, thank you for pointing it out). It gives user a clever
> message in the end of a stack trace like
>
> > UnsupportedPythonVersion: pyignite requires Python '>=3.4' but the
> > running Python is 2.7.15
>
> This feature is not 100% bullet-proof, and it will not help users who will
> try to install my client other way than with `pip` or `setup.py`.
> It will also be less helpful with old versions of `pip` (before 9.0).
> However, it should cover most situations.
>
> On 9/4/18 7:15 PM, Nikolay Izhikov wrote:
>
>> Hello, Dmitry.
>>
>> I understand that for experienced Python developer it obvious from
>> stack trace I send.
>>
>> But can we check python version on startup? And print big fat error
>> message "You are using wrong python version".
>>
> >
>
>> From my experience, there are some tickets in Ignite that should be
>> implemented in various thin clients. It a very trivial changes, but
>> lack of testability makes this task harder then steel.
>>
>> I think a .Net DEVNOTES are very good example.
>>
>> Please, be gentle with your fellow contributors and make DEVNOTES as
>> clear as possible.
>>
>

[Dmitry Melnichuk]

Dmitriy,

It would be quite messy to implement with Python modular system.

First of all, Python 2 and Python 3 are different languages with a small
common subset of syntax rules. That's why what we see in a stack trace
is a syntax error, and not a “missing feature” error.

Second, there is no single entry point in Python code. User is allowed
to import any name, from any module, in any order. In fact the module is
run when it first discovered by CPython during any `import` operation,
and that is how the imported entities are created and initialized: by
the chain of imports.

It means for us, that implementing even a simple compatibility message
in Python 2 requires any module in our program (or at least all the
modules, that represent the public API of our library) to consist
entirely of a valid Python 2 code.

It can be achieved by writing stubs with a version check, putting said
stubs in place of real modules, and proxying all the calls through the
conditional imports. It would take a small effort once, but make code
less readable and harder to maintain for the rest of its life cycle.
Should we, for example, provide two testing environments − for the main
program and for Python 2-compatible stubs?

As far as I know, no Python developer is making such efforts nowadays.
There are some projects with a long history, that achieve
2/3-compatibility through the use of restricted syntax and external
packages like `six`, or simply support two separate versions. Most of
the new projects are creating with the latest Python 3, pip and
virtualenv in mind.

I took the idea of my `setup.py` solution from the Django project, which
is dropped Python 2 support not long ago. Its setup relies on
`setuptools` 9+ option, or otherwise displays a simple banner; the
banner is likely to be buried under the further cryptic output of old
setuptools, but it is better than nothing.

On 9/5/18 2:21 AM, Dmitriy Setrakyan wrote:

> Dmitriy,
>
> setuptools sounds like an installation step. Does it make sense to add a
> check during startup of a client?
>
> D.
>
> On Tue, Sep 4, 2018 at 7:25 AM, Dmitry Melnichuk <
> [hidden email]> wrote:
>
>> Nikolay,
>>
>> There is indeed a feature in `setuptools` I just learned about, which
>> would help in this case (and I believe the case you demonstrated can be
>> quite typical, thank you for pointing it out). It gives user a clever
>> message in the end of a stack trace like
>>
>>> UnsupportedPythonVersion: pyignite requires Python '>=3.4' but the
>>> running Python is 2.7.15
>>
>> This feature is not 100% bullet-proof, and it will not help users who will
>> try to install my client other way than with `pip` or `setup.py`.
>> It will also be less helpful with old versions of `pip` (before 9.0).
>> However, it should cover most situations.
>>
>> On 9/4/18 7:15 PM, Nikolay Izhikov wrote:
>>
>>> Hello, Dmitry.
>>>
>>> I understand that for experienced Python developer it obvious from
>>> stack trace I send.
>>>
>>> But can we check python version on startup? And print big fat error
>>> message "You are using wrong python version".
>>>
>>>
>>
>>>  From my experience, there are some tickets in Ignite that should be
>>> implemented in various thin clients. It a very trivial changes, but
>>> lack of testability makes this task harder then steel.
>>>
>>> I think a .Net DEVNOTES are very good example.
>>>
>>> Please, be gentle with your fellow contributors and make DEVNOTES as
>>> clear as possible.
>>>
>>
>

[dsetrakyan]

Got it, sounds good!

On Tue, Sep 4, 2018 at 10:54 AM, Dmitry Melnichuk <
[hidden email]> wrote:

> Dmitriy,
>
> It would be quite messy to implement with Python modular system.
>
> First of all, Python 2 and Python 3 are different languages with a small
> common subset of syntax rules. That's why what we see in a stack trace is a
> syntax error, and not a “missing feature” error.
>
> Second, there is no single entry point in Python code. User is allowed to
> import any name, from any module, in any order. In fact the module is run
> when it first discovered by CPython during any `import` operation, and that
> is how the imported entities are created and initialized: by the chain of
> imports.
>
> It means for us, that implementing even a simple compatibility message in
> Python 2 requires any module in our program (or at least all the modules,
> that represent the public API of our library) to consist entirely of a
> valid Python 2 code.
>
> It can be achieved by writing stubs with a version check, putting said
> stubs in place of real modules, and proxying all the calls through the
> conditional imports. It would take a small effort once, but make code less
> readable and harder to maintain for the rest of its life cycle. Should we,
> for example, provide two testing environments − for the main program and
> for Python 2-compatible stubs?
>
> As far as I know, no Python developer is making such efforts nowadays.
> There are some projects with a long history, that achieve 2/3-compatibility
> through the use of restricted syntax and external packages like `six`, or
> simply support two separate versions. Most of the new projects are creating
> with the latest Python 3, pip and virtualenv in mind.
>
> I took the idea of my `setup.py` solution from the Django project, which
> is dropped Python 2 support not long ago. Its setup relies on `setuptools`
> 9+ option, or otherwise displays a simple banner; the banner is likely to
> be buried under the further cryptic output of old setuptools, but it is
> better than nothing.
>
>
> On 9/5/18 2:21 AM, Dmitriy Setrakyan wrote:
>
>> Dmitriy,
>>
>> setuptools sounds like an installation step. Does it make sense to add a
>> check during startup of a client?
>>
>> D.
>>
>> On Tue, Sep 4, 2018 at 7:25 AM, Dmitry Melnichuk <
>> [hidden email]> wrote:
>>
>> Nikolay,
>>>
>>> There is indeed a feature in `setuptools` I just learned about, which
>>> would help in this case (and I believe the case you demonstrated can be
>>> quite typical, thank you for pointing it out). It gives user a clever
>>> message in the end of a stack trace like
>>>
>>> UnsupportedPythonVersion: pyignite requires Python '>=3.4' but the
>>>> running Python is 2.7.15
>>>>
>>>
>>> This feature is not 100% bullet-proof, and it will not help users who
>>> will
>>> try to install my client other way than with `pip` or `setup.py`.
>>> It will also be less helpful with old versions of `pip` (before 9.0).
>>> However, it should cover most situations.
>>>
>>> On 9/4/18 7:15 PM, Nikolay Izhikov wrote:
>>>
>>> Hello, Dmitry.
>>>>
>>>> I understand that for experienced Python developer it obvious from
>>>> stack trace I send.
>>>>
>>>> But can we check python version on startup? And print big fat error
>>>> message "You are using wrong python version".
>>>>
>>>>
>>>>
>>>  From my experience, there are some tickets in Ignite that should be
>>>> implemented in various thin clients. It a very trivial changes, but
>>>> lack of testability makes this task harder then steel.
>>>>
>>>> I think a .Net DEVNOTES are very good example.
>>>>
>>>> Please, be gentle with your fellow contributors and make DEVNOTES as
>>>> clear as possible.
>>>>
>>>>
>>>
>>
>

[Igor Sapego-2]

Guys, I've cloned your repository, run pip3 install -e .
then run pip3 install -r requirements/* over all the requirements,
and finally run python ./setup.py pytest, but get the following output:

running pytest
Searching for attrs==18.1.0
Best match: attrs 18.1.0

Using /home/isapego/.local/lib/python3.6/site-packages
running egg_info
writing pyignite.egg-info/PKG-INFO
writing dependency_links to pyignite.egg-info/dependency_links.txt
writing requirements to pyignite.egg-info/requires.txt
writing top-level names to pyignite.egg-info/top_level.txt
reading manifest file 'pyignite.egg-info/SOURCES.txt'
writing manifest file 'pyignite.egg-info/SOURCES.txt'
running build_ext
Traceback (most recent call last):
  File "./setup.py", line 98, in <module>
    'Operating System :: OS Independent',
  File
"/home/isapego/.local/lib/python3.6/site-packages/setuptools/__init__.py",
line 140, in setup
    return distutils.core.setup(**attrs)
  File "/usr/lib/python3.6/distutils/core.py", line 148, in setup
    dist.run_commands()
  File "/usr/lib/python3.6/distutils/dist.py", line 955, in run_commands
    self.run_command(cmd)
  File "/usr/lib/python3.6/distutils/dist.py", line 974, in run_command
    cmd_obj.run()
  File "/home/isapego/.local/lib/python3.6/site-packages/ptr.py", line 175,
in run
    with self.project_on_sys_path():
  File "/usr/lib/python3.6/contextlib.py", line 81, in __enter__
    return next(self.gen)
  File
"/home/isapego/.local/lib/python3.6/site-packages/setuptools/command/test.py",
line 166, in project_on_sys_path
    require('%s==%s' % (ei_cmd.egg_name, ei_cmd.egg_version))
  File
"/home/isapego/.local/lib/python3.6/site-packages/pkg_resources/__init__.py",
line 895, in require
    needed = self.resolve(parse_requirements(requirements))
  File
"/home/isapego/.local/lib/python3.6/site-packages/pkg_resources/__init__.py",
line 786, in resolve
    raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.ContextualVersionConflict: (attrs 18.2.0
(/home/isapego/.local/lib/python3.6/site-packages),
Requirement.parse('attrs==18.1.0'), {'pyignite'})

What am I doing wrong?

Best Regards,
Igor


On Wed, Sep 5, 2018 at 3:19 AM Dmitriy Setrakyan <[hidden email]>
wrote:

> Got it, sounds good!
>
> On Tue, Sep 4, 2018 at 10:54 AM, Dmitry Melnichuk <
> [hidden email]> wrote:
>
> > Dmitriy,
> >
> > It would be quite messy to implement with Python modular system.
> >
> > First of all, Python 2 and Python 3 are different languages with a small
> > common subset of syntax rules. That's why what we see in a stack trace
> is a
> > syntax error, and not a “missing feature” error.
> >
> > Second, there is no single entry point in Python code. User is allowed to
> > import any name, from any module, in any order. In fact the module is run
> > when it first discovered by CPython during any `import` operation, and
> that
> > is how the imported entities are created and initialized: by the chain of
> > imports.
> >
> > It means for us, that implementing even a simple compatibility message in
> > Python 2 requires any module in our program (or at least all the modules,
> > that represent the public API of our library) to consist entirely of a
> > valid Python 2 code.
> >
> > It can be achieved by writing stubs with a version check, putting said
> > stubs in place of real modules, and proxying all the calls through the
> > conditional imports. It would take a small effort once, but make code
> less
> > readable and harder to maintain for the rest of its life cycle. Should
> we,
> > for example, provide two testing environments − for the main program and
> > for Python 2-compatible stubs?
> >
> > As far as I know, no Python developer is making such efforts nowadays.
> > There are some projects with a long history, that achieve
> 2/3-compatibility
> > through the use of restricted syntax and external packages like `six`, or
> > simply support two separate versions. Most of the new projects are
> creating
> > with the latest Python 3, pip and virtualenv in mind.
> >
> > I took the idea of my `setup.py` solution from the Django project, which
> > is dropped Python 2 support not long ago. Its setup relies on
> `setuptools`
> > 9+ option, or otherwise displays a simple banner; the banner is likely to
> > be buried under the further cryptic output of old setuptools, but it is
> > better than nothing.
> >
> >
> > On 9/5/18 2:21 AM, Dmitriy Setrakyan wrote:
> >
> >> Dmitriy,
> >>
> >> setuptools sounds like an installation step. Does it make sense to add a
> >> check during startup of a client?
> >>
> >> D.
> >>
> >> On Tue, Sep 4, 2018 at 7:25 AM, Dmitry Melnichuk <
> >> [hidden email]> wrote:
> >>
> >> Nikolay,
> >>>
> >>> There is indeed a feature in `setuptools` I just learned about, which
> >>> would help in this case (and I believe the case you demonstrated can be
> >>> quite typical, thank you for pointing it out). It gives user a clever
> >>> message in the end of a stack trace like
> >>>
> >>> UnsupportedPythonVersion: pyignite requires Python '>=3.4' but the
> >>>> running Python is 2.7.15
> >>>>
> >>>
> >>> This feature is not 100% bullet-proof, and it will not help users who
> >>> will
> >>> try to install my client other way than with `pip` or `setup.py`.
> >>> It will also be less helpful with old versions of `pip` (before 9.0).
> >>> However, it should cover most situations.
> >>>
> >>> On 9/4/18 7:15 PM, Nikolay Izhikov wrote:
> >>>
> >>> Hello, Dmitry.
> >>>>
> >>>> I understand that for experienced Python developer it obvious from
> >>>> stack trace I send.
> >>>>
> >>>> But can we check python version on startup? And print big fat error
> >>>> message "You are using wrong python version".
> >>>>
> >>>>
> >>>>
> >>>  From my experience, there are some tickets in Ignite that should be
> >>>> implemented in various thin clients. It a very trivial changes, but
> >>>> lack of testability makes this task harder then steel.
> >>>>
> >>>> I think a .Net DEVNOTES are very good example.
> >>>>
> >>>> Please, be gentle with your fellow contributors and make DEVNOTES as
> >>>> clear as possible.
> >>>>
> >>>>
> >>>
> >>
> >
>

[Dmitry Melnichuk]

Igor,

I literally followed the steps you describe, but unfortunately could not
reproduce the error.

The only clue I got is that your site-packages already have the newer
version of attrs (18.2.0 against 18.1.0 as of pyignite requirements).
But this should not be an issue, since pytest-runner in this command
creates its own test environment, independent of the one it runs into.
It worked for me when I installed `attrs==18.2.0` locally and run tests
− everything went smooth.

You can try uninstalling or downgrading your local attrs with

```
$ pip3 uninstall attrs
```

but I don't think it will actually help. Maybe it will raise another
error, so we could dig deeper into the problem.

Alternatively, you can give me more details to recreate it (OS, Python
and pip versions). I'm not ruling out a bug in setuptools.

On 9/11/18 2:13 AM, Igor Sapego wrote:

> Guys, I've cloned your repository, run pip3 install -e .
> then run pip3 install -r requirements/* over all the requirements,
> and finally run python ./setup.py pytest, but get the following output:
>
> running pytest
> Searching for attrs==18.1.0
> Best match: attrs 18.1.0
>
> Using /home/isapego/.local/lib/python3.6/site-packages
> running egg_info
> writing pyignite.egg-info/PKG-INFO
> writing dependency_links to pyignite.egg-info/dependency_links.txt
> writing requirements to pyignite.egg-info/requires.txt
> writing top-level names to pyignite.egg-info/top_level.txt
> reading manifest file 'pyignite.egg-info/SOURCES.txt'
> writing manifest file 'pyignite.egg-info/SOURCES.txt'
> running build_ext
> Traceback (most recent call last):
>    File "./setup.py", line 98, in <module>
>      'Operating System :: OS Independent',
>    File
> "/home/isapego/.local/lib/python3.6/site-packages/setuptools/__init__.py",
> line 140, in setup
>      return distutils.core.setup(**attrs)
>    File "/usr/lib/python3.6/distutils/core.py", line 148, in setup
>      dist.run_commands()
>    File "/usr/lib/python3.6/distutils/dist.py", line 955, in run_commands
>      self.run_command(cmd)
>    File "/usr/lib/python3.6/distutils/dist.py", line 974, in run_command
>      cmd_obj.run()
>    File "/home/isapego/.local/lib/python3.6/site-packages/ptr.py", line 175,
> in run
>      with self.project_on_sys_path():
>    File "/usr/lib/python3.6/contextlib.py", line 81, in __enter__
>      return next(self.gen)
>    File
> "/home/isapego/.local/lib/python3.6/site-packages/setuptools/command/test.py",
> line 166, in project_on_sys_path
>      require('%s==%s' % (ei_cmd.egg_name, ei_cmd.egg_version))
>    File
> "/home/isapego/.local/lib/python3.6/site-packages/pkg_resources/__init__.py",
> line 895, in require
>      needed = self.resolve(parse_requirements(requirements))
>    File
> "/home/isapego/.local/lib/python3.6/site-packages/pkg_resources/__init__.py",
> line 786, in resolve
>      raise VersionConflict(dist, req).with_context(dependent_req)
> pkg_resources.ContextualVersionConflict: (attrs 18.2.0
> (/home/isapego/.local/lib/python3.6/site-packages),
> Requirement.parse('attrs==18.1.0'), {'pyignite'})
>
> What am I doing wrong?
>
> Best Regards,
> Igor
>

[Igor Sapego-2]

I managed to start tests, and now I'm getting the following message:

pyignite.exceptions.HandshakeError: Handshake error: Unsupported
version. Expected protocol version: 1.1.0.

It would be useful to print "Unexpected version" itself, because I can
not understand what is the issue.

Best Regards,
Igor


On Tue, Sep 11, 2018 at 10:34 AM Dmitry Melnichuk <
[hidden email]> wrote:

> Igor,
>
> I literally followed the steps you describe, but unfortunately could not
> reproduce the error.
>
> The only clue I got is that your site-packages already have the newer
> version of attrs (18.2.0 against 18.1.0 as of pyignite requirements).
> But this should not be an issue, since pytest-runner in this command
> creates its own test environment, independent of the one it runs into.
> It worked for me when I installed `attrs==18.2.0` locally and run tests
> − everything went smooth.
>
> You can try uninstalling or downgrading your local attrs with
>
> ```
> $ pip3 uninstall attrs
> ```
>
> but I don't think it will actually help. Maybe it will raise another
> error, so we could dig deeper into the problem.
>
> Alternatively, you can give me more details to recreate it (OS, Python
> and pip versions). I'm not ruling out a bug in setuptools.
>
> On 9/11/18 2:13 AM, Igor Sapego wrote:
> > Guys, I've cloned your repository, run pip3 install -e .
> > then run pip3 install -r requirements/* over all the requirements,
> > and finally run python ./setup.py pytest, but get the following output:
> >
> > running pytest
> > Searching for attrs==18.1.0
> > Best match: attrs 18.1.0
> >
> > Using /home/isapego/.local/lib/python3.6/site-packages
> > running egg_info
> > writing pyignite.egg-info/PKG-INFO
> > writing dependency_links to pyignite.egg-info/dependency_links.txt
> > writing requirements to pyignite.egg-info/requires.txt
> > writing top-level names to pyignite.egg-info/top_level.txt
> > reading manifest file 'pyignite.egg-info/SOURCES.txt'
> > writing manifest file 'pyignite.egg-info/SOURCES.txt'
> > running build_ext
> > Traceback (most recent call last):
> >    File "./setup.py", line 98, in <module>
> >      'Operating System :: OS Independent',
> >    File
> >
> "/home/isapego/.local/lib/python3.6/site-packages/setuptools/__init__.py",
> > line 140, in setup
> >      return distutils.core.setup(**attrs)
> >    File "/usr/lib/python3.6/distutils/core.py", line 148, in setup
> >      dist.run_commands()
> >    File "/usr/lib/python3.6/distutils/dist.py", line 955, in run_commands
> >      self.run_command(cmd)
> >    File "/usr/lib/python3.6/distutils/dist.py", line 974, in run_command
> >      cmd_obj.run()
> >    File "/home/isapego/.local/lib/python3.6/site-packages/ptr.py", line
> 175,
> > in run
> >      with self.project_on_sys_path():
> >    File "/usr/lib/python3.6/contextlib.py", line 81, in __enter__
> >      return next(self.gen)
> >    File
> >
> "/home/isapego/.local/lib/python3.6/site-packages/setuptools/command/test.py",
> > line 166, in project_on_sys_path
> >      require('%s==%s' % (ei_cmd.egg_name, ei_cmd.egg_version))
> >    File
> >
> "/home/isapego/.local/lib/python3.6/site-packages/pkg_resources/__init__.py",
> > line 895, in require
> >      needed = self.resolve(parse_requirements(requirements))
> >    File
> >
> "/home/isapego/.local/lib/python3.6/site-packages/pkg_resources/__init__.py",
> > line 786, in resolve
> >      raise VersionConflict(dist, req).with_context(dependent_req)
> > pkg_resources.ContextualVersionConflict: (attrs 18.2.0
> > (/home/isapego/.local/lib/python3.6/site-packages),
> > Requirement.parse('attrs==18.1.0'), {'pyignite'})
> >
> > What am I doing wrong?
> >
> > Best Regards,
> > Igor
> >
>

[Pavel Petroshenko]

Hi Igor,

Did you have to do anything special to make the tests eventually run?

p.

On Tue, Sep 11, 2018 at 9:13 AM, Igor Sapego <[hidden email]> wrote:

> I managed to start tests, and now I'm getting the following message:
>
> pyignite.exceptions.HandshakeError: Handshake error: Unsupported
> version. Expected protocol version: 1.1.0.
>
> It would be useful to print "Unexpected version" itself, because I can
> not understand what is the issue.
>
> Best Regards,
> Igor
>
>
> On Tue, Sep 11, 2018 at 10:34 AM Dmitry Melnichuk <
> [hidden email]> wrote:
>
> > Igor,
> >
> > I literally followed the steps you describe, but unfortunately could not
> > reproduce the error.
> >
> > The only clue I got is that your site-packages already have the newer
> > version of attrs (18.2.0 against 18.1.0 as of pyignite requirements).
> > But this should not be an issue, since pytest-runner in this command
> > creates its own test environment, independent of the one it runs into.
> > It worked for me when I installed `attrs==18.2.0` locally and run tests
> > − everything went smooth.
> >
> > You can try uninstalling or downgrading your local attrs with
> >
> > ```
> > $ pip3 uninstall attrs
> > ```
> >
> > but I don't think it will actually help. Maybe it will raise another
> > error, so we could dig deeper into the problem.
> >
> > Alternatively, you can give me more details to recreate it (OS, Python
> > and pip versions). I'm not ruling out a bug in setuptools.
> >
> > On 9/11/18 2:13 AM, Igor Sapego wrote:
> > > Guys, I've cloned your repository, run pip3 install -e .
> > > then run pip3 install -r requirements/* over all the requirements,
> > > and finally run python ./setup.py pytest, but get the following output:
> > >
> > > running pytest
> > > Searching for attrs==18.1.0
> > > Best match: attrs 18.1.0
> > >
> > > Using /home/isapego/.local/lib/python3.6/site-packages
> > > running egg_info
> > > writing pyignite.egg-info/PKG-INFO
> > > writing dependency_links to pyignite.egg-info/dependency_links.txt
> > > writing requirements to pyignite.egg-info/requires.txt
> > > writing top-level names to pyignite.egg-info/top_level.txt
> > > reading manifest file 'pyignite.egg-info/SOURCES.txt'
> > > writing manifest file 'pyignite.egg-info/SOURCES.txt'
> > > running build_ext
> > > Traceback (most recent call last):
> > >    File "./setup.py", line 98, in <module>
> > >      'Operating System :: OS Independent',
> > >    File
> > >
> > "/home/isapego/.local/lib/python3.6/site-packages/
> setuptools/__init__.py",
> > > line 140, in setup
> > >      return distutils.core.setup(**attrs)
> > >    File "/usr/lib/python3.6/distutils/core.py", line 148, in setup
> > >      dist.run_commands()
> > >    File "/usr/lib/python3.6/distutils/dist.py", line 955, in
> run_commands
> > >      self.run_command(cmd)
> > >    File "/usr/lib/python3.6/distutils/dist.py", line 974, in
> run_command
> > >      cmd_obj.run()
> > >    File "/home/isapego/.local/lib/python3.6/site-packages/ptr.py",
> line
> > 175,
> > > in run
> > >      with self.project_on_sys_path():
> > >    File "/usr/lib/python3.6/contextlib.py", line 81, in __enter__
> > >      return next(self.gen)
> > >    File
> > >
> > "/home/isapego/.local/lib/python3.6/site-packages/
> setuptools/command/test.py",
> > > line 166, in project_on_sys_path
> > >      require('%s==%s' % (ei_cmd.egg_name, ei_cmd.egg_version))
> > >    File
> > >
> > "/home/isapego/.local/lib/python3.6/site-packages/pkg_
> resources/__init__.py",
> > > line 895, in require
> > >      needed = self.resolve(parse_requirements(requirements))
> > >    File
> > >
> > "/home/isapego/.local/lib/python3.6/site-packages/pkg_
> resources/__init__.py",
> > > line 786, in resolve
> > >      raise VersionConflict(dist, req).with_context(dependent_req)
> > > pkg_resources.ContextualVersionConflict: (attrs 18.2.0
> > > (/home/isapego/.local/lib/python3.6/site-packages),
> > > Requirement.parse('attrs==18.1.0'), {'pyignite'})
> > >
> > > What am I doing wrong?
> > >
> > > Best Regards,
> > > Igor
> > >
> >
>

[Dmitry Melnichuk]

Igor,

I have just commited an improvment to the HandshakeError message
generation algorithm. I hope it is now easier to understand what expects
what in case of binary protocol version mismatch.

Thank you for pointing this out.

On 9/12/18 2:13 AM, Igor Sapego wrote:

> I managed to start tests, and now I'm getting the following message:
>
> pyignite.exceptions.HandshakeError: Handshake error: Unsupported
> version. Expected protocol version: 1.1.0.
>
> It would be useful to print "Unexpected version" itself, because I can
> not understand what is the issue.
>
> Best Regards,
> Igor

[Igor Sapego-2]

Pavel,
Yes, I did. I tried completely clean environment, followed the same
steps and got the same error. Then I removed attr, and out of sudden
everything started working.

Dmitry,
Thanks, now it's more clear:
Handshake error: Unsupported version. Server expects binary protocol
version 1.1.0. Client provides 1.2.0.

Why do you use version 1.2.0, but have outdated server code? I
propose you to merge with or rebase onto Ignite's master branch.

Best Regards,
Igor


On Tue, Sep 11, 2018 at 11:21 PM Dmitry Melnichuk <
[hidden email]> wrote:

> Igor,
>
> I have just commited an improvment to the HandshakeError message
> generation algorithm. I hope it is now easier to understand what expects
> what in case of binary protocol version mismatch.
>
> Thank you for pointing this out.
>
> On 9/12/18 2:13 AM, Igor Sapego wrote:
> > I managed to start tests, and now I'm getting the following message:
> >
> > pyignite.exceptions.HandshakeError: Handshake error: Unsupported
> > version. Expected protocol version: 1.1.0.
> >
> > It would be useful to print "Unexpected version" itself, because I can
> > not understand what is the issue.
> >
> > Best Regards,
> > Igor
>

[Dmitry Melnichuk]

Igor,

Yes, it's my bad, sorry. Just merged the Ignite master with my branch.

On 9/12/18 8:47 PM, Igor Sapego wrote:

> Pavel,
> Yes, I did. I tried completely clean environment, followed the same
> steps and got the same error. Then I removed attr, and out of sudden
> everything started working.
>
> Dmitry,
> Thanks, now it's more clear:
> Handshake error: Unsupported version. Server expects binary protocol
> version 1.1.0. Client provides 1.2.0.
>
> Why do you use version 1.2.0, but have outdated server code? I
> propose you to merge with or rebase onto Ignite's master branch.
>
> Best Regards,
> Igor
>
>
> On Tue, Sep 11, 2018 at 11:21 PM Dmitry Melnichuk <
> [hidden email]> wrote:
>
>> Igor,
>>
>> I have just commited an improvment to the HandshakeError message
>> generation algorithm. I hope it is now easier to understand what expects
>> what in case of binary protocol version mismatch.
>>
>> Thank you for pointing this out.
>>
>> On 9/12/18 2:13 AM, Igor Sapego wrote:
>>> I managed to start tests, and now I'm getting the following message:
>>>
>>> pyignite.exceptions.HandshakeError: Handshake error: Unsupported
>>> version. Expected protocol version: 1.1.0.
>>>
>>> It would be useful to print "Unexpected version" itself, because I can
>>> not understand what is the issue.
>>>
>>> Best Regards,
>>> Igor
>>
>

[Igor Sapego-2]

Ok, now everything's running.

API looks good to me. I have a single question about example code:
What these comments are for - [1]?

[1] -
https://github.com/nobitlost/ignite/blob/ignite-7782/modules/platforms/python/examples/create_binary.py#L95

Best Regards,
Igor


On Thu, Sep 13, 2018 at 12:52 AM Dmitry Melnichuk <
[hidden email]> wrote:

> Igor,
>
> Yes, it's my bad, sorry. Just merged the Ignite master with my branch.
>
> On 9/12/18 8:47 PM, Igor Sapego wrote:
> > Pavel,
> > Yes, I did. I tried completely clean environment, followed the same
> > steps and got the same error. Then I removed attr, and out of sudden
> > everything started working.
> >
> > Dmitry,
> > Thanks, now it's more clear:
> > Handshake error: Unsupported version. Server expects binary protocol
> > version 1.1.0. Client provides 1.2.0.
> >
> > Why do you use version 1.2.0, but have outdated server code? I
> > propose you to merge with or rebase onto Ignite's master branch.
> >
> > Best Regards,
> > Igor
> >
> >
> > On Tue, Sep 11, 2018 at 11:21 PM Dmitry Melnichuk <
> > [hidden email]> wrote:
> >
> >> Igor,
> >>
> >> I have just commited an improvment to the HandshakeError message
> >> generation algorithm. I hope it is now easier to understand what expects
> >> what in case of binary protocol version mismatch.
> >>
> >> Thank you for pointing this out.
> >>
> >> On 9/12/18 2:13 AM, Igor Sapego wrote:
> >>> I managed to start tests, and now I'm getting the following message:
> >>>
> >>> pyignite.exceptions.HandshakeError: Handshake error: Unsupported
> >>> version. Expected protocol version: 1.1.0.
> >>>
> >>> It would be useful to print "Unexpected version" itself, because I can
> >>> not understand what is the issue.
> >>>
> >>> Best Regards,
> >>> Igor
> >>
> >
>
>

[Dmitry Melnichuk]

Igor,

The commented code (lines 95-96) gives an error if executed. The error
is stated just below, in lines 98-100. It is explained here:

https://apache-ignite-binary-protocol-client.readthedocs.io/en/latest/examples.html#create

I found out by trial and error that a cache, created with SQL DDL
statement (`CREATE TABLE`), can be deleted only with SQL DDL statement
(`DROP TABLE`), whereas a table, created with a binary protocol
operation (`OP_CACHE_CREATE_*` or `OP_CACHE_GET_OR_CREATE_*`) can be
deleted only with binary protocol operation (`OP_CACHE_DESTROY`). I miss
this fact in Ignite documentation.

In this particular part of the example I try to stress this out with
regard to the cache created in the beginning of the example. The cache
behaves like an SQL table, but can not be dropped. You need to destroy
it instead (line 102).

I would not go into such depths at all, but the examples are designed to
be runnable in automated environments, and thus must have some cleanup
code. And since the cleanup here is not absolutely trivial, I thought I
must explain it.

I also could handle an error instead of commenting the erroneous code, like

```
any_error = None
try:
     DROP_QUERY = 'DROP TABLE Student'
     client.sql(DROP_QUERY)
except Exception as e:
     any_error = e
print(any_error)

# pyignite.exceptions.SQLError: class
org.apache.ignite.IgniteCheckedException:
# Only cache created with CREATE TABLE may be removed with DROP TABLE
# [cacheName=SQL_PUBLIC_STUDENT]

but it would complicate the cleanup part of the example to the point it
is lost any exemplariness. So I decided to simply use comments.

On 9/14/18 2:48 AM, Igor Sapego wrote:

> Ok, now everything's running.
>
> API looks good to me. I have a single question about example code:
> What these comments are for - [1]?
>
> [1] -
> https://github.com/nobitlost/ignite/blob/ignite-7782/modules/platforms/python/examples/create_binary.py#L95
>
> Best Regards,
> Igor
>
>
> On Thu, Sep 13, 2018 at 12:52 AM Dmitry Melnichuk <
> [hidden email]> wrote:
>
>> Igor,
>>
>> Yes, it's my bad, sorry. Just merged the Ignite master with my branch.
>>
>> On 9/12/18 8:47 PM, Igor Sapego wrote:
>>> Pavel,
>>> Yes, I did. I tried completely clean environment, followed the same
>>> steps and got the same error. Then I removed attr, and out of sudden
>>> everything started working.
>>>
>>> Dmitry,
>>> Thanks, now it's more clear:
>>> Handshake error: Unsupported version. Server expects binary protocol
>>> version 1.1.0. Client provides 1.2.0.
>>>
>>> Why do you use version 1.2.0, but have outdated server code? I
>>> propose you to merge with or rebase onto Ignite's master branch.
>>>
>>> Best Regards,
>>> Igor
>>>
>>>
>>> On Tue, Sep 11, 2018 at 11:21 PM Dmitry Melnichuk <
>>> [hidden email]> wrote:
>>>
>>>> Igor,
>>>>
>>>> I have just commited an improvment to the HandshakeError message
>>>> generation algorithm. I hope it is now easier to understand what expects
>>>> what in case of binary protocol version mismatch.
>>>>
>>>> Thank you for pointing this out.
>>>>
>>>> On 9/12/18 2:13 AM, Igor Sapego wrote:
>>>>> I managed to start tests, and now I'm getting the following message:
>>>>>
>>>>> pyignite.exceptions.HandshakeError: Handshake error: Unsupported
>>>>> version. Expected protocol version: 1.1.0.
>>>>>
>>>>> It would be useful to print "Unexpected version" itself, because I can
>>>>> not understand what is the issue.
>>>>>
>>>>> Best Regards,
>>>>> Igor
>>>>
>>>
>>
>>
>

[Igor Sapego-2]

Ok, good.

Now, what is about installation? Which directories/files
need to be copied to ignite's binary release?

Best Regards,
Igor


On Fri, Sep 14, 2018 at 4:51 AM Dmitry Melnichuk <
[hidden email]> wrote:

> Igor,
>
> The commented code (lines 95-96) gives an error if executed. The error
> is stated just below, in lines 98-100. It is explained here:
>
>
> https://apache-ignite-binary-protocol-client.readthedocs.io/en/latest/examples.html#create
>
> I found out by trial and error that a cache, created with SQL DDL
> statement (`CREATE TABLE`), can be deleted only with SQL DDL statement
> (`DROP TABLE`), whereas a table, created with a binary protocol
> operation (`OP_CACHE_CREATE_*` or `OP_CACHE_GET_OR_CREATE_*`) can be
> deleted only with binary protocol operation (`OP_CACHE_DESTROY`). I miss
> this fact in Ignite documentation.
>
> In this particular part of the example I try to stress this out with
> regard to the cache created in the beginning of the example. The cache
> behaves like an SQL table, but can not be dropped. You need to destroy
> it instead (line 102).
>
> I would not go into such depths at all, but the examples are designed to
> be runnable in automated environments, and thus must have some cleanup
> code. And since the cleanup here is not absolutely trivial, I thought I
> must explain it.
>
> I also could handle an error instead of commenting the erroneous code, like
>
> ```
> any_error = None
> try:
>      DROP_QUERY = 'DROP TABLE Student'
>      client.sql(DROP_QUERY)
> except Exception as e:
>      any_error = e
> print(any_error)
>
> # pyignite.exceptions.SQLError: class
> org.apache.ignite.IgniteCheckedException:
> # Only cache created with CREATE TABLE may be removed with DROP TABLE
> # [cacheName=SQL_PUBLIC_STUDENT]
>
> but it would complicate the cleanup part of the example to the point it
> is lost any exemplariness. So I decided to simply use comments.
>
> On 9/14/18 2:48 AM, Igor Sapego wrote:
> > Ok, now everything's running.
> >
> > API looks good to me. I have a single question about example code:
> > What these comments are for - [1]?
> >
> > [1] -
> >
> https://github.com/nobitlost/ignite/blob/ignite-7782/modules/platforms/python/examples/create_binary.py#L95
> >
> > Best Regards,
> > Igor
> >
> >
> > On Thu, Sep 13, 2018 at 12:52 AM Dmitry Melnichuk <
> > [hidden email]> wrote:
> >
> >> Igor,
> >>
> >> Yes, it's my bad, sorry. Just merged the Ignite master with my branch.
> >>
> >> On 9/12/18 8:47 PM, Igor Sapego wrote:
> >>> Pavel,
> >>> Yes, I did. I tried completely clean environment, followed the same
> >>> steps and got the same error. Then I removed attr, and out of sudden
> >>> everything started working.
> >>>
> >>> Dmitry,
> >>> Thanks, now it's more clear:
> >>> Handshake error: Unsupported version. Server expects binary protocol
> >>> version 1.1.0. Client provides 1.2.0.
> >>>
> >>> Why do you use version 1.2.0, but have outdated server code? I
> >>> propose you to merge with or rebase onto Ignite's master branch.
> >>>
> >>> Best Regards,
> >>> Igor
> >>>
> >>>
> >>> On Tue, Sep 11, 2018 at 11:21 PM Dmitry Melnichuk <
> >>> [hidden email]> wrote:
> >>>
> >>>> Igor,
> >>>>
> >>>> I have just commited an improvment to the HandshakeError message
> >>>> generation algorithm. I hope it is now easier to understand what
> expects
> >>>> what in case of binary protocol version mismatch.
> >>>>
> >>>> Thank you for pointing this out.
> >>>>
> >>>> On 9/12/18 2:13 AM, Igor Sapego wrote:
> >>>>> I managed to start tests, and now I'm getting the following message:
> >>>>>
> >>>>> pyignite.exceptions.HandshakeError: Handshake error: Unsupported
> >>>>> version. Expected protocol version: 1.1.0.
> >>>>>
> >>>>> It would be useful to print "Unexpected version" itself, because I
> can
> >>>>> not understand what is the issue.
> >>>>>
> >>>>> Best Regards,
> >>>>> Igor
> >>>>
> >>>
> >>
> >>
> >
>
>

[Dmitry Melnichuk]

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
>

[Igor Sapego-2]

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 <
[hidden email]> 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
> >
>