Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DEPLOCK: Create initial Lockfile checker and generator #2

Closed
7 tasks done
pombredanne opened this issue May 1, 2024 · 6 comments
Closed
7 tasks done

DEPLOCK: Create initial Lockfile checker and generator #2

pombredanne opened this issue May 1, 2024 · 6 comments
Assignees

Comments

@pombredanne
Copy link
Member

pombredanne commented May 1, 2024

There are many ways to get the resolved dependencies of a project. Some of these are:

  1. Run the package manager(s) "install" command to fetch and install locally the dependencies, then scan them
  2. Run the package manager(s) command to generate lockfiles then parse and collect
  3. Collect the deps from parsing an existing lockfile or lockfile-like file
  4. Run the package manager(s) command to resolve the dependencies, then parse the output or files generated from these commands
  5. Run some tool to simulate the dependency resolution, then parse the output or files generated from these commands
  6. Run a build and trace it with tracecode to collect fetched archives, and used files

Unless there is a locked, reproducible build process (backed by committed lockfiles as in 3.), all approaches are approximations of the dependency resolution. (Short of yet another approach with a binary, deployed code analysis)

Yet, 1,2,4, and 5 all require some extensive setup or guessing to setup a build environment as it is arbitrarily hard to reproduce the build environments reliably at scale.

Therefore, I propose a different approach here:

  • Check if there are lockfiles available, optionally fail when not
  • When there is no lockfile available, generate one by providing instructions and tools to run this IN THE CONTEXT OF THE BUILD, by and with the project team intimate understanding of this build
  • If there is no such lockfile in the ecosystem (such as Maven), invent one from existing or new tools and promote conventions on naming, format and location
  • Then always parse a pre-computed, lockfile
  • Ensure that we merge lockfiles with their parent package manifest (in SCTK)

Separately, continue supporting dependency resolution simulation with all its problems with the various inspectors.

Some insights and concrete todos:

See #13 for package types beyond this first batch

@pombredanne
Copy link
Member Author

pombredanne commented May 1, 2024

An alternative to detecting and checking which package ecosystem and lockfiles are needed would be to provide explicitly which package manager(s) are used in the project, likely in a scancode-config.yml file honored by SCIO and SCTK.

We would then only need to maintain a map of package manager to required lockfiles and fail when these are not present.

Then in SCTK and SCIO we could also focus the detection and parsing of package manifests and lockfiles to the subset reported to be in use in a given codebase.

@pombredanne
Copy link
Member Author

We have a few options:

  1. create our own tool more or less from scratch
  2. reuse and extend an existing tool that would approach the feature set we want or provide a great base like Add new command to trace build deps and files jelmer/ognibuild#119

Say the tool is called "genlock", then to generate a yarn lockfile for #3 I would like the tool to run a yarn install when I run genlock --yarn

@pombredanne
Copy link
Member Author

There is also a large body of reusable tools for the GitHub dependency API submission. See https://github.com/search?q=dependency-submission&type=repositories

@pombredanne
Copy link
Member Author

This tool should be used before a scan and should therefore have as few deps as possible.
Ideally this should be a single, standalone file, "statically linked", self-executable.
There a few options:

  • Rely on an interpreter pre-installed, like Bash or Python.
    • Bash would be weak and painful to debug
    • Python would be great but with some issues:
      • Relying on pre-installed Python may often not prove true
      • Avoid any dependencies, including dependencies on certain Python version, may be difficult.
  • Use Python and bundle Python with it in a single/standalone exe (https://github.com/indygreg/PyOxidizer or https://pyinstaller.org)
  • Build a native single exe binary using Go, Rust or Haskell (built to run on each OS)

@pombredanne pombredanne changed the title Create a Lockfile checker and generator Create initial Lockfile checker and generator Jun 10, 2024
@pombredanne pombredanne changed the title Create initial Lockfile checker and generator DEPLOCK: Create initial Lockfile checker and generator Jun 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants