FS#60247 - [python-awkward] Does not include correct dependencies

Attached to Project: Community Packages
Opened by Konstantin Gizdov (kgizdov) - Saturday, 29 September 2018, 17:38 GMT
Last edited by Felix Yan (felixonmars) - Sunday, 14 October 2018, 21:38 GMT
Task Type Feature Request
Category Packages
Status Closed
Assigned To Felix Yan (felixonmars)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


Package was taken over from AUR and it no longer includes its correct dependencies. Package depends on multiple other for certain features:

arrow, bcolz, dask, numpa

Is it planned to include them in a next release?
This task depends upon

Closed by  Felix Yan (felixonmars)
Sunday, 14 October 2018, 21:38 GMT
Reason for closing:  Not a bug
Additional comments about closing:  See comments.
Comment by loqs (loqs) - Saturday, 29 September 2018, 18:05 GMT
Packages in the official repositories can not have AUR dependencies. So to add those dependencies arrow, bcolz, dask and numba would also need to be added to the official repositories.
Comment by Konstantin Gizdov (kgizdov) - Saturday, 29 September 2018, 18:56 GMT
OK, I'm confused. Why has this been taken over then if maintainer does not plan to support all features of the package. Arch policy is to build and include everything, so maintainer should take over the rest of the dependencies and include them, no?
Comment by Doug Newgard (Scimmia) - Saturday, 29 September 2018, 19:01 GMT
That is not Arch policy
Comment by Konstantin Gizdov (kgizdov) - Saturday, 29 September 2018, 19:09 GMT
Now I'm even more confused. I've been packaging a lot of professional software in AUR for years now and this was definitely a comment brought up by Eli Schwartz when I was originally starting to package and asking for advice and how to follow properly. Maybe I misunderstood. Now however, this package is part of a dependency chain of mine, conflicts with my AUR version a does not provide same functionality. What is the correct thing to do?
Comment by Filipe Laíns (FFY00) - Saturday, 29 September 2018, 21:27 GMT
The package can be used without those features thus making them optional dependencies. We shouldn't force a user to install them if he's not gonna need them.

If the package requires building something to be able to use a dependency, then that dependency should be included in makedepends. This results in the package having support for such feature but not having an hard dependency on them. If the optional dependencies are not in the official repos, then support shouldn't be added. The maintainer might consider to move them to the official repos but it's not forced to.

With this said, that isn't even the case in this package, contrarily to what you implied. Being a python package, the packaging process is only to optimize the files (generate .pyc/.pyo files) and install everything. No dependency is actually needed for the build process (at least usually).

You can just install the optional dependencies from the AUR and use everything just like you used to.
Comment by Konstantin Gizdov (kgizdov) - Saturday, 29 September 2018, 21:58 GMT
I know how dependencies and python packages work. I depend on this package, which was the original reason I put it on AUR. Now my dependency tree has orphans and users don't have a clue about the benefits/features of the optional dependencies, because it has been packaged in an incomplete way and does list them.
Comment by Filipe Laíns (FFY00) - Saturday, 29 September 2018, 22:47 GMT
Just tell your users to install the optional dependencies. What's the big deal here?? I don't get it.
Comment by Eli Schwartz (eschwartz) - Sunday, 30 September 2018, 01:37 GMT
  • Field changed: Task Type (Bug Report → Feature Request)
  • Field changed: Status (Unconfirmed → Assigned)
  • Task assigned to Felix Yan (felixonmars)
The README.md for the upstream project lists those modules as "Recommended dependencies" but does not list their use in setup.py under extras_require. Furthermore, I cannot find reference to them in the source code...

What actually brings in these (opt)depends?

Also, as observed above, the package does not have any decreased functionality, although admittedly it is annoying to be unaware of the possibility of additional dependencies.


All this being said... The PyPI name is "awkward", but the github name is "awkward-array". The AUR package is named according to the latter, the [community] name corresponds to the former.
Given the mismatch here, I'm not sure felixonmars realized there was an existing package, and perhaps therefore never thought about possibly adding those other dependencies.

There is no harm in asking him if he would like to add these in order to make python-awkward more fully-featured, hence I will assign this ticket to him -- as a feature request, since it is not a bug.
He may or may not choose to do so.
Comment by Felix Yan (felixonmars) - Sunday, 30 September 2018, 04:46 GMT
Actually the mentioned "dependencies" are general optimizations/enhancements for numpy itself, hardly related to awkward (other than in the README). If some software rely on them I would suggest to add them there, which is more correct. Please correct me if I am wrong, though.
Comment by Eli Schwartz (eschwartz) - Sunday, 30 September 2018, 04:57 GMT
So these are in fact optdepends modifying the behavior of numpy itself? That would seem to fit with my inability to find anything else about it outside the README...
Comment by Konstantin Gizdov (kgizdov) - Sunday, 30 September 2018, 19:06 GMT
Yes, that seems to be correct. I only added this to AUR a couple of weeks ago and didn't have time to go through all things. I believe they were direct optional dependencies (you can find traces in the old tests), but not anymore. You can probably close this or move it to numpy as awkward-array package would definitely benefit from the features given its functionality.
Comment by Felix Yan (felixonmars) - Sunday, 14 October 2018, 21:38 GMT
After double checking with these dependencies I believe they need to be explicitly imported and used to gain mentioned functionality, so it's not an optdepend of numpy or awkward-array. Anything that can actually make use of them should consider to add them respectively.