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

Add supports field. #11

Closed
pjf opened this issue Sep 24, 2014 · 2 comments · Fixed by #416
Closed

Add supports field. #11

pjf opened this issue Sep 24, 2014 · 2 comments · Fixed by #416
Labels
Core (ckan.dll) Issues affecting the core part of CKAN Easy This is easy to fix Spec Issues affecting the spec

Comments

@pjf
Copy link
Member

pjf commented Sep 24, 2014

We currently have a recommends list, does it make sense to have a supports list? This would be useful for things like TweakScale or RealismOverhaul, which provide support for a wide range of mods, but which don't necessary recommend them.

Having a supports field allows quick and machine-friendly answers to questions like "does this work with TweakScale", which is possibly the number one question I've seen asked of any mod I follow.

The rich metadata side of me wants this very much, and wants to include it even if we don't use it in initial implementations. The getting things done side of me says that this is a distraction and I should go back to coding. :)

@pjf pjf added the design label Sep 24, 2014
@pjf pjf added ★☆☆ Spec Issues affecting the spec Policy Issues with our policy and removed design labels Oct 21, 2014
@pjf
Copy link
Member Author

pjf commented Oct 23, 2014

So, I think we should have this. One of the most common questions I see is "does it have TweakScale integration", or "does it work with ReaismOverhaul"? Crawling over forums to find that is tiresome and not always productive.

An explicit supports field answers these questions. In a possible awesome future, users can right-click on a mod in the supports panel of the GUI and select install. Likewise a mod could even be decorated with supported by X or suggested by Y information in metadata viewers.

So even though this is the weakest relationship of all, I think it's still useful to have. (And completely optional)

@pjf
Copy link
Member Author

pjf commented Oct 23, 2014

Flipping this to an actionable issue, but feel free to say that we shouldn't have this if you disagree. I'm just trying to maximise future global utility. ;)

@pjf pjf changed the title RFC: Supports field? Add supports field. Oct 23, 2014
@pjf pjf added Easy This is easy to fix Core (ckan.dll) Issues affecting the core part of CKAN and removed Policy Issues with our policy labels Oct 23, 2014
pjf referenced this issue in KSP-CKAN/NetKAN Nov 7, 2014
Thanks @SirDiazo for an awesome mod. :)
This was referenced Nov 19, 2014
@pjf pjf closed this as completed in #416 Nov 26, 2014
@pjf pjf removed the ★☆☆ label Nov 26, 2014
RichardLake pushed a commit to RichardLake/CKAN that referenced this issue May 30, 2015
Add a --all option to upgrade.
HebaruSan pushed a commit that referenced this issue May 4, 2020
Co-authored-by: DasSkelett <DasSkelett@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Core (ckan.dll) Issues affecting the core part of CKAN Easy This is easy to fix Spec Issues affecting the spec
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant