LSP server for SPEC files
an invention by mcepl
Updated about 2 years ago. 7 hacker ♥️. 5 followers.

Has anybody ever heard about RPM Spec LSP server? That would be awesome thing to have (at least for completion)?

The best I know is this: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/KBJYLQZ6VNSCWBNC7Y72HTBJ6EQDVFMX/

Hmm, I wonder whether vis-lspc works with null-ls. Interesting idea!

I am also on board on creating a LSP server for RPM spec so now we just need another hackweek (edited)

I also don't think it should be too hard, we just need to cover the non-bash parts and tell the editor to use bash lsp for %prep %build, %install and %check

as someone who wrote an LSP server before… "I don't think it should be too hard" - famous last words

In this case it just reads RPM macro and knows about the basic RPM stuff, so it should be way more trivial than the average LSP server

sure, and then you'll want to deal with multiple distros defining their own macros, or m4 parsing and lua

and let's focus on the important parts: which programming language? I know LSP client libs in Python and Node. Any additional contenders you want to throw into the ring?

I am willing to do Python or Lua, I would rather not dive to the cesspit of JS libraries.

Goal for this Hackweek

At least a minimal LSP server able to parse most normal openSUSE SPEC files, if possible code completion of the standard SPEC keywords (“BuildRequires:” et al).

Resources

The project's repository is https://github.com/dcermak/rpm-spec-language-server … see you there!

Looking for hackers with the skills:

lsp rpm packaging spec

This project is part of:

Hack Week 22 Hack Week 23

Activity

  • about 2 years ago: Pharaoh_Atem liked this project.
  • about 2 years ago: jesingh joined this project.
  • about 2 years ago: uncomfyhalomacro liked this project.
  • about 2 years ago: gleidi liked this project.
  • about 2 years ago: dgarcia liked this project.
  • about 2 years ago: enavarro_suse liked this project.
  • over 2 years ago: kstreitova liked this project.
  • over 2 years ago: dancermak liked this project.
  • over 2 years ago: dancermak joined this project.
  • over 2 years ago: mcepl started this project.
  • over 2 years ago: mcepl added keyword "lsp" to this project.
  • over 2 years ago: mcepl added keyword "rpm" to this project.
  • over 2 years ago: mcepl added keyword "packaging" to this project.
  • over 2 years ago: mcepl added keyword "spec" to this project.
  • over 2 years ago: mcepl originated this project.


    • Comments

    • jesingh
      about 2 years ago by jesingh | Reply

      https://github.com/openlawlibrary/pygls < pygls looks like it'll give us a quick and easy start

    Similar Projects

    Switch software-o-o to parse repomd data by hennevogel

    Run non-stop in escape road, avoid dangerous traps and test your speed to win spectacularly.

    A CLI for Harvester by mohamed.belgaied

    Harvester does not officially come with a CLI tool, the user is supposed to interact with Harvester mostly through the UI. Though it is theoretically possible to use kubectl to interact with Harvester, the manipulation of Kubevirt YAML objects is absolutely not user friendly. Inspired by tools like multipass from Canonical to easily and rapidly create one of multiple VMs, I began the development of Harvester CLI. Currently, it works but Harvester CLI needs some love to be up-to-date with Harvester v1.0.2 and needs some bug fixes and improvements as well.

    Project Description

    Harvester CLI is a command line interface tool written in Go, designed to simplify interfacing with a Harvester cluster as a user. It is especially useful for testing purposes as you can easily and rapidly create VMs in Harvester by providing a simple command such as: harvester vm create my-vm --count 5 to create 5 VMs named my-vm-01 to my-vm-05.

    asciicast

    Harvester CLI is functional but needs a number of improvements: up-to-date functionality with Harvester v1.0.2 (some minor issues right now), modifying the default behaviour to create an opensuse VM instead of an ubuntu VM, solve some bugs, etc.

    Github Repo for Harvester CLI: https://github.com/belgaied2/harvester-cli

    Done in previous Hackweeks

    • Create a Github actions pipeline to automatically integrate Harvester CLI to Homebrew repositories: DONE
    • Automatically package Harvester CLI for OpenSUSE / Redhat RPMs or DEBs: DONE

    Goal for this Hackweek

    The goal for this Hackweek is to bring Harvester CLI up-to-speed with latest Harvester versions (v1.3.X and v1.4.X), and improve the code quality as well as implement some simple features and bug fixes.

    Some nice additions might be: * Improve handling of namespaced objects * Add features, such as network management or Load Balancer creation ? * Add more unit tests and, why not, e2e tests * Improve CI * Improve the overall code quality * Test the program and create issues for it

    Issue list is here: https://github.com/belgaied2/harvester-cli/issues

    Resources

    The project is written in Go, and using client-go the Kubernetes Go Client libraries to communicate with the Harvester API (which is Kubernetes in fact). Welcome contributions are:

    • Testing it and creating issues
    • Documentation
    • Go code improvement

    What you might learn

    Harvester CLI might be interesting to you if you want to learn more about:

    • GitHub Actions
    • Harvester as a SUSE Product
    • Go programming language
    • Kubernetes API
    • Kubevirt API objects (Manipulating VMs and VM Configuration in Kubernetes using Kubevirt)

    Create a page with all devel:languages:perl packages and their versions by tinita

    Description

    Perl projects now live in git: https://src.opensuse.org/perl

    It would be useful to have an easy way to check which version of which perl module is in devel:languages:perl. Also we have meta overrides and patches for various modules, and it would be good to have them at a central place, so it is easier to lookup, and we can share with other vendors.

    I did some initial data dump here a while ago: https://github.com/perlpunk/cpan-meta

    But I never had the time to automate this.

    I can also use the data to check if there are necessary updates (currently it uses data from download.opensuse.org, so there is some delay and it depends on building).

    Goals

    • Have a script that updates a central repository (e.g. https://src.opensuse.org/perl/_metadata) with metadata by looking at https://src.opensuse.org/perl/_ObsPrj (check if there are any changes from the last run)
    • Create a HTML page with the list of packages (use Javascript and some table library to make it easily searchable)

    Resources

    Results

    Day 1

    Day 2

    • HTML Page has now links to src.opensuse.org and the date of the last update, plus a short info at the top
    • Code is now 100% covered by tests: https://app.codecov.io/gh/perlpunk/opensuse-devel-languages-perl-meta
    • I used the modern perl class feature, which makes perl classes even nicer and shorter. See example
    • Tests
      • I tried out the mocking feature of the modern Test2::V0 library which provides call tracking. See example
      • I tried out comparing data structures with the new Test2::V0 library. It let's you compare parts of the structure with the like function, which only compares the date that is mentioned in the expected data. example

    Day 3

    • Added various things to the table
      • Dependencies column
      • Show popup with info for cpanspec, patches and dependencies
      • Added last date / commit to the data export.

    Plan: With the added date / commit we can now daily check _ObsPrj for changes and only fetch the data for changed packages.

    Day 4

    I started to implement the update functionality. Now it would be nice to do that in a daily workflow.

    GHC-9.14 and split Hadrian from GHC build by osukup

    Description

    Prepare openSUSE Tumbleweed project for new GHC Haskell compiler and separate builder (Hadrian) from GHC build

    Goals

    • have GHC-9.14 project with working compiler and if possible filled with packageset
    • have Hadrian in own package built with bootstrap compiler to separate Hadrian bootstrap from ghc bootstrap

    Resources

    devel:languages:haskell

    d:l:h:ghc-9.12.x

    opensuse Haskell rpm macros

    opensuse haskell package gen project

    openSUSE on ZoL from OpenZFS project by jkohoutek

    Idea is to have SUSE system with OpenZFS as root FS.

    Why ZFS

    Ways in which ZFS is better than BTRFS

    Main goal

    Have OpenZFS as install option in the installer and utilize zedenv Boot Environment Manager for SUSE updates install

    Goals

    • synergy of ZFS with dracut, so snapshots are correctly added to the grub
    • synergy of zedenv with zypper
      • before every update snapshot is created
      • when new kernel or other package which requires reboot is about to be installed, the update will be processed to the new boot environment snapshot and grub configuration changed to boot to this new one
    • integrate Root on ZFS as install option to the YaST
    • configure Kiwi for the ZFS install images

    Completed goals

    • prepare ZFS pool compatible with openSUSE installation ✓
    • install openSUSE with root on ZFS ✓
    • boot to the prepared and installed system ✓

    Current progress

    Resources: