Background and motivation
Adopting PackageGuard starts with an empty configuration file and a question the user cannot answer yet: which licenses should I allow? The only way to find out is to write a guess, run the tool, read the failures, and iterate. That is a poor first experience, and it is the moment where most evaluations are abandoned.
The tool already has everything needed to answer the question, because after one scan it knows exactly which licenses and packages are actually present.
Proposal
An interactive command that scans the repository, summarises what it found, and writes a configuration reflecting the current reality:
Scanning C:\src\MyProduct...
Found 247 packages across 12 projects.
Licenses in use:
MIT 184 packages
Apache-2.0 41 packages
BSD-3-Clause 9 packages
MS-PL 7 packages
LGPL-2.1-only 4 packages <- weak copyleft
GPL-3.0-only 2 packages <- strong copyleft
(unknown) 1 package <- SomeObscurePackage 1.2.0
What kind of software is this?
> Proprietary / commercial (suggests: permissive only)
SaaS / hosted (suggests: no network copyleft)
Open source (suggests: OSS friendly)
Written .packageguard/config.json
2 packages violate the suggested policy. Run `packageguard .` to see them.
Design points:
- Show reality before asking for a decision. Listing what is actually in the repository, with counts and copyleft flagged, is the part that makes the choice informed rather than arbitrary.
- Do not silently allow everything present. Generating a config that permits exactly what is already there produces a policy that can never fail and gives false confidence. Suggesting a sensible policy and then reporting what does not fit is the honest outcome.
- Non-interactive mode.
packageguard init --preset permissive-only --yes for scripted setup and for use in templates.
- Never overwrite silently. If a configuration already exists, refuse unless
--force is given.
- Explain the copyleft distinction. A one-line explanation of what LGPL or GPL means for the user's situation is more valuable at this moment than anywhere else in the documentation.
- Comments in the generated file. The config format already tolerates comments (the README example uses them), so the generated file can explain each section inline.
This pairs naturally with policy presets: init picks the closest preset and the generated file simply extends it, keeping it short and upgradable.
Alternative Concerns
- The README already contains a copyable example, which is cheap and helps, but it does not reflect the user's actual dependencies.
- A
--suggest-config flag on the normal analyze command would achieve something similar without a new command, though it fits the mental model less well.
Are you willing help with a pull-request?
No
Background and motivation
Adopting PackageGuard starts with an empty configuration file and a question the user cannot answer yet: which licenses should I allow? The only way to find out is to write a guess, run the tool, read the failures, and iterate. That is a poor first experience, and it is the moment where most evaluations are abandoned.
The tool already has everything needed to answer the question, because after one scan it knows exactly which licenses and packages are actually present.
Proposal
An interactive command that scans the repository, summarises what it found, and writes a configuration reflecting the current reality:
Design points:
packageguard init --preset permissive-only --yesfor scripted setup and for use in templates.--forceis given.This pairs naturally with policy presets:
initpicks the closest preset and the generated file simply extends it, keeping it short and upgradable.Alternative Concerns
--suggest-configflag on the normal analyze command would achieve something similar without a new command, though it fits the mental model less well.Are you willing help with a pull-request?
No