ariatosca-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ARIA-96) Dependency versions strictness / conflicts
Date Thu, 23 Mar 2017 18:15:45 GMT

    [ https://issues.apache.org/jira/browse/ARIA-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15938940#comment-15938940
] 

ASF subversion and git services commented on ARIA-96:
-----------------------------------------------------

Commit 76f6623572cee0d135a91bd90f45e3a2c7b61412 in incubator-ariatosca's branch refs/heads/ARIA-120-Builtin-workflows-relationship-operations-execution-order
from [~avia]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-ariatosca.git;h=76f6623 ]

ARIA-96 Improve our requirements handling

1. Currently, don't vendor any library.

2. Use pip-tools (specifically, pip-compile) to manage our dependencies
   requirement files.

3. requirements.in:
   The requirements.in will be read into `install_requires`, and includes
   loose dependencies (as possible, and only direct dependencies), as is
   common when installing using a setup.py file.
   Since we haven't tested ARIA with many versions of our dependencies, our
   dependencies are not very loose, but we are hoping to improve this as
   our project matures.
   Currently, when we provide an upper bound, it is either because of python
   2.6 compatibility, or according to a semantic versioning (i.e. future
   versions that could break the current API). Lower boundaries are
   usually the lowest version that we tested with ARIA, or because version
   before are lacking functionality we are using.

4. requirements.txt:
   The requirements.txt is generated from requirements.in via pip-compile,
   and includes fixed-version dependencies, including all transitive
   dependencies, in order to provide an stable environment that ARIA is
   ensured to work on.


> Dependency versions strictness / conflicts
> ------------------------------------------
>
>                 Key: ARIA-96
>                 URL: https://issues.apache.org/jira/browse/ARIA-96
>             Project: AriaTosca
>          Issue Type: Story
>            Reporter: Ran Ziv
>            Assignee: Avia Efrat
>             Fix For: 0.1.0
>
>
> When ARIA is used by another project, it might lead to dependency versions conflicts.
> Dependency versions should be made less strict (i.e. ranges).
> Alternatively we could consider vendoring some of the more common dependencies inside
ARIA.
> --------------------------------------------------------------------------------------------------------------------------
> Our conclusions:
> 1. Currently, don't vendor any library.
> 2. Use pip-tools (specifically, pip-compile) to manage our dependencies / requirement
files.
> 3. requirements.in:
> The requirements.in will be read into `install_requires`, and includes loose dependencies
(as possible, and only direct dependencies), as is common when installing using a setup.py
file.
> Since we haven't tested ARIA with many versions of our dependencies, our dependencies
are not very loose, but we are hoping to improve this as our project matures.
> Currently, when we provide an upper bound, it is either because of python 2.6 compatibility,
or according to a semantic versioning (i.e. future versions that could break the current API).
Lower boundaries are usually the lowest version that we tested with ARIA, or because version
before are lacking functionality we are using.
> 4. requirements.txt:
> The requirements.txt is generated from requirements.in via pip-compile, and includes
fixed-version dependencies, including all transitive dependencies, in order to provide an
stable environment that ARIA is ensured to work on.
> 5. python 2.6 compatible dependencies:
> As pip-compile currently does not provide support for conditional dependencies (https://github.com/jazzband/pip-tools/issues/435),
we are adding these dependencies explicitly in the setup.py via `extras_require`, and manually
in the generated requirements.txt. We are also mentioning this issue in a comment in requirements.in.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message