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

Powershell functions: Allow access to package title, not only ID #925

Closed
andmos opened this Issue Aug 23, 2016 · 8 comments

Comments

Projects
None yet
3 participants
@andmos
Contributor

andmos commented Aug 23, 2016

Small issue, but here goes:
In the environment variables available from the ChocolateyInstall.ps1 scripts we get access to the package ID and version. In some cases the title of the package is also usefull - especially if it will be presented a little nicer for the user.

Example:
When adding packages to the registry to uninstall from "Add / Remove programs" - dialogue in Windows is best to give the title of the package, not just the id. It looks better for the user.

I propose a chocolateyPackageTitle variable or similar.
Any thoughts?

@ferventcoder

This comment has been minimized.

Show comment
Hide comment
@ferventcoder

ferventcoder Aug 23, 2016

Member

Sure, sounds good. Perhaps make other items available as well?

Member

ferventcoder commented Aug 23, 2016

Sure, sounds good. Perhaps make other items available as well?

andmos added a commit to andmos/choco that referenced this issue Aug 24, 2016

(chocolateyGH-925) Make package title available to $env
Some times the title of the package must be presented to the user in a
"pretty" matter. The Package Id helps, but is not "GUI-friendly".
To avoid the need to parse the Id ourselves, this adds the access to the
package title as an environment variable.
@andmos

This comment has been minimized.

Show comment
Hide comment
@andmos

andmos Aug 24, 2016

Contributor

I decided to just take the variable I am looking for. I like to not introduce code before I actually need it 😄 Hope that is ok!

Contributor

andmos commented Aug 24, 2016

I decided to just take the variable I am looking for. I like to not introduce code before I actually need it 😄 Hope that is ok!

@jberezanski

This comment has been minimized.

Show comment
Hide comment
@jberezanski

jberezanski Aug 24, 2016

Member

Could it be a PowerShell variable, not an environment variable? Adding more and more env vars pollutes the environment and increases memory consumption of every proces started by choco during package installation (and on Windows XP there is a limit for the size of the environment block).

Member

jberezanski commented Aug 24, 2016

Could it be a PowerShell variable, not an environment variable? Adding more and more env vars pollutes the environment and increases memory consumption of every proces started by choco during package installation (and on Windows XP there is a limit for the size of the environment block).

@jberezanski

This comment has been minimized.

Show comment
Hide comment
@jberezanski

jberezanski Aug 24, 2016

Member

Additionally, one PowerShell variable could store an object with several properties describing the package, making the interface cleaner (one variable instead of many) and easier to extend (just add a property to the object).

Member

jberezanski commented Aug 24, 2016

Additionally, one PowerShell variable could store an object with several properties describing the package, making the interface cleaner (one variable instead of many) and easier to extend (just add a property to the object).

@andmos

This comment has been minimized.

Show comment
Hide comment
@andmos

andmos Aug 24, 2016

Contributor

Yeah the thought has struck me that environment variables might not be the most effective way here. Rewriting it will take some more effort and knowledge about the code, so I will leave that to @ferventcoder!

Contributor

andmos commented Aug 24, 2016

Yeah the thought has struck me that environment variables might not be the most effective way here. Rewriting it will take some more effort and knowledge about the code, so I will leave that to @ferventcoder!

@jberezanski

This comment has been minimized.

Show comment
Hide comment
@jberezanski

jberezanski Aug 24, 2016

Member

I'm concerned because once something is added and documented as public interface it is most likely to stick forever, as changing it will break packages that started depending on it. That's why I'd like to see it done the more desired way from the beginning.

Member

jberezanski commented Aug 24, 2016

I'm concerned because once something is added and documented as public interface it is most likely to stick forever, as changing it will break packages that started depending on it. That's why I'd like to see it done the more desired way from the beginning.

@andmos

This comment has been minimized.

Show comment
Hide comment
@andmos

andmos Aug 24, 2016

Contributor

Yeah, I am just "adding to the pattern" if you will, but that is how I found the code. We have already used some of these variables in a lot of packages, so it would be a breaking change. Doesn't mean that it should not be done, but a rewrite should be signaled with a obsolete-tag or something like that. Again, I leave this for @ferventcoder!

Contributor

andmos commented Aug 24, 2016

Yeah, I am just "adding to the pattern" if you will, but that is how I found the code. We have already used some of these variables in a lot of packages, so it would be a breaking change. Doesn't mean that it should not be done, but a rewrite should be signaled with a obsolete-tag or something like that. Again, I leave this for @ferventcoder!

andmos added a commit to andmos/choco that referenced this issue Aug 24, 2016

(chocolateyGH-925) Make package title available to $env
Some times the title of the package must be presented to the user in a
"pretty" matter. The Package Id helps, but is not "GUI-friendly".
To avoid the need to parse the Id ourselves, this adds the access to the
package title as an environment variable.

andmos added a commit to andmos/choco that referenced this issue Aug 24, 2016

(chocolateyGH-925) Make package title available to $env
Some times the title of the package must be presented to the user in a
"pretty" matter. The Package Id helps, but is not "GUI-friendly".
To avoid the need to parse the Id ourselves, this adds the access to the
package title as an environment variable.

@ferventcoder ferventcoder added 1 - Ready and removed 0 - Backlog labels Aug 24, 2016

@ferventcoder ferventcoder modified the milestones: 0.10.1, 0.10.x Aug 24, 2016

@ferventcoder ferventcoder self-assigned this Aug 24, 2016

ferventcoder added a commit that referenced this issue Sep 12, 2016

(GH-925) Make package title available to $env
Some times the title of the package must be presented to the user in a
"pretty" matter. The Package Id helps, but is not "GUI-friendly".
To avoid the need to parse the Id ourselves, this adds the access to the
package title as an environment variable.

ferventcoder added a commit that referenced this issue Sep 12, 2016

Merge branch 'pr928' into stable
* pr928:
  (GH-925) Make package title available to $env

ferventcoder added a commit that referenced this issue Sep 12, 2016

Merge branch 'stable'
* stable:
  (GH-925) Make package title available to $env
  (GH-920) Fix missing $ in Get-FtpFile
@ferventcoder

This comment has been minimized.

Show comment
Hide comment
@ferventcoder

ferventcoder Sep 12, 2016

Member

This will be released with 0.10.1. Thanks!

Member

ferventcoder commented Sep 12, 2016

This will be released with 0.10.1. Thanks!

@ferventcoder ferventcoder added 3 - Done and removed 1 - Ready labels Sep 12, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment