Mailing-List: contact issues-help@ariatosca.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ariatosca.incubator.apache.org
Date: Wed, 13 Sep 2017 11:21:00 +0000 (UTC)
From: "Ran Ziv (JIRA)" <jira@apache.org>
To: issues@ariatosca.apache.org
Message-ID: <JIRA.13101927.1505301543000.100765.1505301660127@Atlassian.JIRA>
In-Reply-To: <JIRA.13101927.1505301543000@Atlassian.JIRA>
References: <JIRA.13101927.1505301543000@Atlassian.JIRA> <JIRA.13101927.1505301543633@jira-lw-us.apache.org>
Subject: [jira] [Updated] (ARIA-368) Setuptools dependency issues
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Wed, 13 Sep 2017 11:21:05 -0000


     [ https://issues.apache.org/jira/browse/ARIA-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ran Ziv updated ARIA-368:
-------------------------
    Description: 
ARIA currently has a direct dependency on {{setuptools}}, which is used for single-sourcing the version (see [this|https://packaging.python.org/guides/single-sourcing-package-version/], item #5 - implemented [here|https://github.com/apache/incubator-ariatosca/blob/0.1.1/aria/__init__.py#L24]).

Having a direct dependency on {{setuptools}} is not recommended in general, plus we currently have in the requirements.in file bounds on the {{setuptools}} package version from both sides (i.e. upper and lower bounds) - which is problematic, as this might cause a downgrade of the current {{setuptools}} version in the environment where ARIA is installed.

Perhaps a different solution for single-sourcing ARIA's version should be implemented, though each of the different solutions suggested in the linked article has its own downsides (keeping in mind the solution also needs to work for binary installations, i.e. environments where the {{setup.py}} file isn't around to be used)

Note that another downside for this implementation is that the package name is not single sourced (i.e. it appears both in {{setup.py}} and in {{aria/__init__.py}})


  was:
ARIA currently has a direct dependency on setuptools, which is used for single-sourcing the version (see [this|https://packaging.python.org/guides/single-sourcing-package-version/], item #5 - implemented [here|https://github.com/apache/incubator-ariatosca/blob/0.1.1/aria/__init__.py#L24]).

Having a direct dependency on setup.py is not recommended in general, plus we currently have in the requirements.in file bounds on the setuptools package version from both sides (i.e. upper and lower bounds) - which is problematic, as this might cause a downgrade of the current setuptools version in the environment where ARIA is installed.

Perhaps a different solution for single-sourcing ARIA's version should be implemented, though each of the different solutions suggested in the linked article has its own downsides (keeping in mind the solution also needs to work for binary installations, i.e. environments where the setup.py file isn't around to be used)

Note that another downside for this implementation is that the package name is not single sourced (i.e. it appears both in `setup.py` and in aria/__init__.py)


> Setuptools dependency issues
> ----------------------------
>
>                 Key: ARIA-368
>                 URL: https://issues.apache.org/jira/browse/ARIA-368
>             Project: AriaTosca
>          Issue Type: Task
>            Reporter: Ran Ziv
>            Priority: Minor
>
> ARIA currently has a direct dependency on {{setuptools}}, which is used for single-sourcing the version (see [this|https://packaging.python.org/guides/single-sourcing-package-version/], item #5 - implemented [here|https://github.com/apache/incubator-ariatosca/blob/0.1.1/aria/__init__.py#L24]).
> Having a direct dependency on {{setuptools}} is not recommended in general, plus we currently have in the requirements.in file bounds on the {{setuptools}} package version from both sides (i.e. upper and lower bounds) - which is problematic, as this might cause a downgrade of the current {{setuptools}} version in the environment where ARIA is installed.
> Perhaps a different solution for single-sourcing ARIA's version should be implemented, though each of the different solutions suggested in the linked article has its own downsides (keeping in mind the solution also needs to work for binary installations, i.e. environments where the {{setup.py}} file isn't around to be used)
> Note that another downside for this implementation is that the package name is not single sourced (i.e. it appears both in {{setup.py}} and in {{aria/__init__.py}})


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)