Spack package out of date

[jfdev001]

Two comments:

1. The link to the upstream repo where the actual spack package is stored is a deadlink. That is,
   

   arbor/doc/contrib/dependency-management.rst

   Line 15 in ef667f6

   In addition, ``spack/package.py`` contains a copy of the Spack package definition `upstream <https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/arbor/package.py>`_. Here instructions for both in-repo and configure-time dependencies are defined.

   
   contains a reference to a dead link. This should be updated to something like https://github.com/spack/spack-packages/blob/c67b7374f164bdf10a7e6f774d99e907a31b2a95/repos/spack_repo/builtin/packages/arbor/package.py. I can open a PR that updates the deadlink, just lmk!

2. The spack/package.py in this repo no longer matches the one in the spack-packages repo. I am not sure what the standard approach is to resolve this since it seems like open-source projects that take an interest in developing a spack package end up just opening a PR to the official spack-package repo rather than defining spack/package.py in their own repo. One approach might be to update the arbor CI to simply pull the spack-package/**/arbor/package.py into this project repo, but perhaps this is too naive. Figured I'd bring this up.

[thorstenhater]

Hi @jfdev001,

thanks for reporting this and sorry for the delay. Our efforts to update the spack package
are unfortunately blocked, as you can see here for example

https://github.com/arbor-sim/arbor/actions/runs/17939161181

this might be due to our method. The idea behind keeping the package definition local is
that we can test it in CI first. However, it seems the hoops we need to go through using
custom spack repos doesn't hold up anymore and we need a new approach.

[jfdev001]

Hi @thorstenhater

Thanks for your response! I am planning on contributing a spack package for FTorch and being really new to spack package development, I ran across the same issue that you identify here. Namely, that you want to develop and test spack package locally before opening PR to the official built-in spack-packages.

I also have to take a local development approach because I am not a core maintainer of FTorch. My current idea is to to first PR a spack package for FTorch to the FTorch repository itself, define a CI action for FTorch to ensure the spack package behaves as expected, get feedback from the core developers that would naturally lead to a more refined CI and spack package itself, and then PR to spack-packages to make FTorch a built-in package. If you have thoughts or comments on this workflow, I would greatly appreciate it since it's a problem that is clearly relevant! I also plan on asking this question in the spack slack.

[jfdev001]

@thorstenhater The advice of one of the maintainers was to PR spack-packages directly and not keep a package.py in one's own repo.

[thorstenhater]

Hi @jfdev001,

thanks for researching this and providing the answer here. Although I'd have preferred another solution.
I'll find the time to adjust the workflow.