[jira] [Updated] (ARIA-368) Setuptools dependency issues

["Ran Ziv (JIRA)" <ji...@apache.org>]

     [ 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 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)


  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 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)



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