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

odo catalog list components should truncate long descriptions #4044

Closed
deboer-tim opened this issue Sep 25, 2020 · 8 comments · Fixed by #4150
Closed

odo catalog list components should truncate long descriptions #4044

deboer-tim opened this issue Sep 25, 2020 · 8 comments · Fixed by #4150
Assignees
Labels
area/UX Issues or PRs related to User Experience kind/feature Categorizes issue as a feature request. For PRs, that means that the PR is the implementation priority/Low Nice to have issue. It's not immediately on the project roadmap to get it done.

Comments

@deboer-tim
Copy link

/kind bug

What versions of software are you using?

Operating System:
MacBook Pro running Catalina

Output of odo version:
odo v2.0.0 (6fbb9d9)

How did you run odo exactly?

odo catalog list components

Actual behavior

Due to one really long description I had to make my console 207 characters wide to be able to read the output:

Odo Devfile Components:
NAME     DESCRIPTION                                                                                                                                                                     REGISTRY

         Che4z Mainframe Basic Stack is an all-in-one extension pack for developers working with z/OS applications, suitable for all levels of mainframe experience, even beginners.     CheDevfileRegistry

Expected behavior

If the description is longer than some reasonable amount (60 chars?) it should be truncated with an ellipsis (...) so that the command is still usable. Especially once users start to create devfiles there could be one that's 200 chars or more.

@openshift-ci-robot openshift-ci-robot added the kind/bug Categorizes issue or PR as related to a bug. label Sep 25, 2020
@girishramnani girishramnani added the area/UX Issues or PRs related to User Experience label Oct 5, 2020
@girishramnani
Copy link
Contributor

technically its not a bug, so making it a feature request

@girishramnani girishramnani added kind/feature Categorizes issue as a feature request. For PRs, that means that the PR is the implementation priority/Low Nice to have issue. It's not immediately on the project roadmap to get it done. and removed kind/bug Categorizes issue or PR as related to a bug. labels Oct 5, 2020
@girishramnani girishramnani self-assigned this Oct 5, 2020
@girishramnani girishramnani removed their assignment Oct 8, 2020
@mohammedzee1000
Copy link
Contributor

mohammedzee1000 commented Oct 22, 2020

@mohammedzee1000
Copy link
Contributor

Ok I got something:

❯ odo catalog list components
Odo Devfile Components:
NAME                 DESCRIPTION                                                                                                                                                                     REGISTRY
                     Stack for developing NodeJS Angular Web Application                                                                                                                             CheRegistry
                     Stack with tooling ready to develop Integration projects with Apache Camel K                                                                                                    CheRegistry
                     Stack with environment ready to develop Integration projects with Apache Camel based on Spring Boot.                                                                            CheRegistry
                     Che4z Mainframe Basic Stack is an all-in-one extension pack for developers working with z/OS applications, suitable for all levels of mainframe experience, even beginners.     CheRegistry
 ❯ ./odo catalog list components
Odo Devfile Components:
NAME                 DESCRIPTION                                                         REGISTRY
                     Stack for developing NodeJS Angular Web Application                 CheRegistry
                     Stack with tooling ready to develop Integration projects wit...     CheRegistry
                     Stack with environment ready to develop Integration projects...     CheRegistry
                     Che4z Mainframe Basic Stack is an all-in-one extension pack ...     CheRegistry

Altho I must say, without a name, that looks weird. Might be a good idea to add names to your stuff

@deboer-tim ^

@mohammedzee1000
Copy link
Contributor

@girishramnani personally, I think name must be a required field

@mohammedzee1000
Copy link
Contributor

How does someone use them without a name? I think we should skip showing entries without names(show why we are skipping in verbose logs)

@deboer-tim
Copy link
Author

FWIW, the missing names were due to having used previous experimental versions of odo and having an old registry configured (and yes, you couldn't do anything with them :) ). Once I fixed that it goes to the current registry and names are ok.

+1 to the ... It does show that stack creators need to be a little more concise in the descriptions, but IMHO that's a good thing and this change will help accelerate it.

@mohammedzee1000
Copy link
Contributor

mohammedzee1000 commented Oct 22, 2020

Ok il have a WIP pr up shortly. Adding tests for this, however, will be harder as we need a devfile in a registry that has an extra-long description by design (that does not get accidentally fixed breaking tests left and right :))

@mohammedzee1000
Copy link
Contributor

mohammedzee1000 commented Oct 27, 2020

FWIW, the missing names were due to having used previous experimental versions of odo and having an old registry configured (and yes, you couldn't do anything with them :) ). Once I fixed that it goes to the current registry and names are ok.

Oki tho I still think we should error if we have entries without a name. It could be graceful like I said, by skipping those and logging it on -v 4 or something

+1 to the ... It does show that stack creators need to be a little more concise in the descriptions, but IMHO that's a good thing and this change will help accelerate it.

Done. PR up. If they cant make it concise, then at least they should now try to fit the most important info in 60 chars :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/UX Issues or PRs related to User Experience kind/feature Categorizes issue as a feature request. For PRs, that means that the PR is the implementation priority/Low Nice to have issue. It's not immediately on the project roadmap to get it done.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants