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