Arch Linux

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.

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?

That is not Arch policy

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?

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.

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.

Just tell your users to install the optional dependencies. What's the big deal here?? I don't get it.

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.

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.

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

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.

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.