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 <dsetrak...@apache.org>
wrote:
> Got it, sounds good!
>
> On Tue, Sep 4, 2018 at 10:54 AM, Dmitry Melnichuk <
> dmitry.melnic...@nobitlost.com> 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 <
> >> dmitry.melnic...@nobitlost.com> 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.
> >>>>
> >>>>
> >>>
> >>
> >
>
