Skip to content
Snippets Groups Projects

Add several packages

Packages included

  • HBP VF Py Client
  • EBRAINS Drive
  • HBP Archive
  • HippoUnit
  • MorphoUnit

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • Hi @shailesh,

    First of all thanks for the effort to provide all these packages.

    I looked into the contributed code and have the below comments. Unfortunately, this particular MR cannot be merged as it is as the build will surely not finish successfully.

    Spack has packages available that should be used when listing dependencies in your Spack packages. Please find the list of things you can install using Spack from here. This means that you need to rename the dependencies that you have listed in your Spack packages to match the names in the Spack built in repository.
    I have tried to include all necessary naming changes below.

    • ebrains-drive/package.py

    requests -> py-requests

    • hbp-archive/package.py

    lxml -> py-lxml
    keystoneauth1 -> py-keystoneauth1
    python-keystoneclient -> py-python-keystoneclient
    python-swiftclient -> py-python-swiftclient

    • hippounit/package.py

    sciunit: does not exist in spack upstream, needs to be packaged
    efel: does not exist in spack upstream, needs to be packaged

    • morphounit/package.py

    neo -> py-neo
    elephant -> py-elephant but on version 0.4.1
    sciunit: does not exist in spack upstream, needs to be packaged
    neurom -> are you refering to neuron ?
    tabulate -> py-tabulate
    seaborn -> py-seaborn

    • vf-py-client/package.py

    requests -> py-requests
    nameparser: does not exist in spack upstream, needs to be packaged
    simplejson -> py-simplejson

    You will notice that:

    1. some dependencies need to be renamed
    2. some dependencies need to be Spack packaged as well, as they are not available in the Spack upstream
    3. in some dependencies you will need to check that the version that you specify as the minimum acceptable version is available in the Spack upstream (example: in requests -> py-requests you specify the dependency as "requests@2.27.0:" so the version must be 2.27.0 or higher but only up to version 2.26.0 is available in the Spack upstream for this package)

    So i suggest that you first try to resolve the above comments and then:

    1. Provide each package in a separate MR so that each component can be built separately (easier to track changes and issues)
    2. Provide also the necessary Spack spec that should go in the spack.yaml file indicating what Spack should build for each of the contributed packages.

    I will wait for your confirmation before closing this MR.
    Thanks

  • Thanks a lot @akarmas for taking the time to look at this MR and for providing the detailed instructions. I shall close this MR now, and create one per package as you recommended (along with all the other required changes).

  • Shailesh Appukuttan mentioned in merge request !62 (merged)

    mentioned in merge request !62 (merged)

  • Shailesh Appukuttan mentioned in merge request !63 (merged)

    mentioned in merge request !63 (merged)

  • Shailesh Appukuttan mentioned in merge request !64 (merged)

    mentioned in merge request !64 (merged)

  • Shailesh Appukuttan mentioned in merge request !65 (merged)

    mentioned in merge request !65 (merged)

  • Shailesh Appukuttan mentioned in merge request !66 (merged)

    mentioned in merge request !66 (merged)

  • Shailesh Appukuttan mentioned in merge request !61 (merged)

    mentioned in merge request !61 (merged)

  • @akarmas: I have now made the changes you pointed out. I have also added the other dependencies that were not already available.

    I did have a small query regarding

    • the naming of the module in spack.yaml
    • the directory name used inside 'packages'
    • the class name used withing package.py for each module

    I followed the pattern I found for PyNN's recipe , where

    name of the module in spack.yaml = directory name used inside 'packages' (e.g. py-pynn)

    the class name used withing package.py did not seem to be linked to anything in specific (e.g. PyPynn)

    I have tried to follow the above for all the modules I have now added. Let me know if there is a different logic/rules for this naming.

    Thanks again for the detailed feedback :pray: It was super helpful.

    Edited by Shailesh Appukuttan
  • Another question @akarmas If I wish to employ a higher version of a package from the Spack package list, e.g. if I need >=13.0 of py-quantities and Spack currently offers this package only upto 0.12.1.... how/where do I add these newer versions?

    Note: the other MRs don't face this issue, and I am asking in context to another package.

    Adding these questions as part of this post, just to have the answers publicly available for other users in future.

Please register or sign in to reply