On Tue Jan 8 20:19:43 UTC 2019, David Runge wrote:
- ruby-websockets-extensions
- pkgname: avoid composition
What should I do?
- arch: single quotes missing
- url: use double quotes
- license: single quotes missing
- depends: single quotes missing
- makedepends: single quotes missing
- package(): _gemdir can be derived from $(gem env gemdir),
Why is use `$(gem env gemdir)`
Instead of
`$(ruby -e'puts Gem.default_dir')`
LICENSE.md can be installed using 'install -t'
Why is use `install -t`
Instead of
`install -D`
``` install --help -D create all leading components of DEST except the last, or all components of --target-directory, then copy SOURCE to DEST
-t, --target-directory=DIRECTORY copy all SOURCE arguments into DIRECTORY ```
On 2019-01-22 17:09:35 (+0800), Metal A-wing wrote:
On Tue Jan 8 20:19:43 UTC 2019, David Runge wrote:
- pkgname: avoid composition
What should I do?
It's more readable and less error-prone to do `pkgname=name` instead of `pkgname="name${something_else}"`.
Why is use `$(gem env gemdir)`
Instead of
`$(ruby -e'puts Gem.default_dir')`
It's shorter and you don't have to spawn a ruby process to print something, if you can use the gem command directly.
LICENSE.md can be installed using 'install -t'
Why is use `install -t`
The upside is, that you can ommit the specific destination (unless you want to rename the destination file). e.g. `install -vDm 644 LICENSE -t "${pkgdir}/usr/share/licenses/${pkgname}/"` creates the directory "${pkgdir}/usr/share/licenses/${pkgname}/" for you, if it doesn't exist and will install the source file to that directory, without you having to specifically name the destination file.
Whereas the following requires you to specify the destination file as well: `install -vDm 644 LICENSE "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
Not using the `-t` flag is only useful, if you need to rename the destination file, e.g.:
`install -vDm 644 WEIRDNAME_FOR_A_LICENSE "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
In short: This is shorter and implies the creation of the destination directory.
Closing: Please use a mail client, that doesn't break threads (i.e. replies to the thread that was initially created, instead of creating a new one. Mailman is somewhat able to order these threads in the list archive, but in mail clients this is horrible to follow up on (there are now 4 separate threads [1] [2] [3] [4]). Compare the 'In-Reply-To' header in the messages with those of others.
Aside from that, happy packaging! :) David
[1] https://lists.archlinux.org/pipermail/aur-general/2018-December/034744.html [2] https://lists.archlinux.org/pipermail/aur-general/2018-December/034758.html [3] https://lists.archlinux.org/pipermail/aur-general/2019-January/034799.html [4] https://lists.archlinux.org/pipermail/aur-general/2019-January/034848.html
David Runge schreef op 2019-01-22 12:30:
On 2019-01-22 17:09:35 (+0800), Metal A-wing wrote:
On Tue Jan 8 20:19:43 UTC 2019, David Runge wrote: Why is use `$(gem env gemdir)`
Instead of
`$(ruby -e'puts Gem.default_dir')`
It's shorter and you don't have to spawn a ruby process to print something, if you can use the gem command directly.
I'm not a TU so take my this with a grain of salt, but I don't think this is the best advice.
It's shorter, admittedly, but `gem` spawns a ruby process just as the `ruby` version does. Using gem doesn't work however when `$GEM_HOME` is set, since then it reports the contents of that variable.
Especially for AUR packages using `$(ruby -e'puts Gem.default_dir')` is more convenient since most users do not build in a clean chroot, and the wiki actually recommends settings that environment variable so quite a few will have it.
Best,
Bert Peters.
On January 22, 2019 1:25:20 PM GMT+01:00, Bert Peters via aur-general aur-general@archlinux.org wrote:
David Runge schreef op 2019-01-22 12:30:
On 2019-01-22 17:09:35 (+0800), Metal A-wing wrote:
On Tue Jan 8 20:19:43 UTC 2019, David Runge wrote: Why is use `$(gem env gemdir)`
Instead of
`$(ruby -e'puts Gem.default_dir')`
It's shorter and you don't have to spawn a ruby process to print something, if you can use the gem command directly.
I'm not a TU so take my this with a grain of salt, but I don't think this is the best advice.
It's shorter, admittedly, but `gem` spawns a ruby process just as the `ruby` version does. Using gem doesn't work however when `$GEM_HOME` is
set, since then it reports the contents of that variable.
Especially for AUR packages using `$(ruby -e'puts Gem.default_dir')` is
more convenient since most users do not build in a clean chroot, and the wiki actually recommends settings that environment variable so quite a few will have it.
Best,
Bert Peters.
Which seems silly and the whole section should be removed in the first place. Thats what --user-install switch should be for and that should be default via /etc/gemrc Therefor setting that is just useless fiddling with the system and your gems will be searched there as well as it's default gem path besides /usr/lib.
Levente Polyak via aur-general schreef op 2019-01-22 13:40:
On January 22, 2019 1:25:20 PM GMT+01:00, Bert Peters via aur-general aur-general@archlinux.org wrote:
David Runge schreef op 2019-01-22 12:30:
On 2019-01-22 17:09:35 (+0800), Metal A-wing wrote:
On Tue Jan 8 20:19:43 UTC 2019, David Runge wrote: Why is use `$(gem env gemdir)`
Instead of
`$(ruby -e'puts Gem.default_dir')`
It's shorter and you don't have to spawn a ruby process to print something, if you can use the gem command directly.
I'm not a TU so take my this with a grain of salt, but I don't think this is the best advice.
It's shorter, admittedly, but `gem` spawns a ruby process just as the `ruby` version does. Using gem doesn't work however when `$GEM_HOME` is
set, since then it reports the contents of that variable.
Especially for AUR packages using `$(ruby -e'puts Gem.default_dir')` is
more convenient since most users do not build in a clean chroot, and the wiki actually recommends settings that environment variable so quite a few will have it.
Best,
Bert Peters.
Which seems silly and the whole section should be removed in the first place. Thats what --user-install switch should be for and that should be default via /etc/gemrc Therefor setting that is just useless fiddling with the system and your gems will be searched there as well as it's default gem path besides /usr/lib.
While `gem` obeys that default, `bundle` (ruby-bundler) does not, and does not have that default, opting for a global install by default. You can override this by manually adding `--path=~/.gem` to every invocation. That's hardly an elegant solution compared to setting an environment variable.
On January 22, 2019 4:03:29 PM GMT+01:00, Bert Peters via aur-general aur-general@archlinux.org wrote:
Levente Polyak via aur-general schreef op 2019-01-22 13:40:
On January 22, 2019 1:25:20 PM GMT+01:00, Bert Peters via aur-general aur-general@archlinux.org wrote:
David Runge schreef op 2019-01-22 12:30:
On 2019-01-22 17:09:35 (+0800), Metal A-wing wrote:
On Tue Jan 8 20:19:43 UTC 2019, David Runge wrote: Why is use `$(gem env gemdir)`
Instead of
`$(ruby -e'puts Gem.default_dir')`
It's shorter and you don't have to spawn a ruby process to print something, if you can use the gem command directly.
I'm not a TU so take my this with a grain of salt, but I don't think this is the best advice.
It's shorter, admittedly, but `gem` spawns a ruby process just as
the
`ruby` version does. Using gem doesn't work however when `$GEM_HOME`
is
set, since then it reports the contents of that variable.
Especially for AUR packages using `$(ruby -e'puts Gem.default_dir')`
is
more convenient since most users do not build in a clean chroot, and the wiki actually recommends settings that environment variable so quite
a
few will have it.
Best,
Bert Peters.
Which seems silly and the whole section should be removed in the
first
place. Thats what --user-install switch should be for and that should be default via /etc/gemrc Therefor setting that is just useless fiddling with the system and your gems will be searched there as well as it's default gem path besides /usr/lib.
While `gem` obeys that default, `bundle` (ruby-bundler) does not, and does not have that default, opting for a global install by default. You can override this by manually adding `--path=~/.gem` to every invocation. That's hardly an elegant solution compared to setting an environment variable.
Which is why "bundle config path" exists. A sane way would be to use that to define BUNDLE_PATH in ~/.bundle/config
Levente Polyak via aur-general schreef op 2019-01-22 16:10:
On January 22, 2019 4:03:29 PM GMT+01:00, Bert Peters via aur-general aur-general@archlinux.org wrote:
Levente Polyak via aur-general schreef op 2019-01-22 13:40:
On January 22, 2019 1:25:20 PM GMT+01:00, Bert Peters via aur-general aur-general@archlinux.org wrote:
David Runge schreef op 2019-01-22 12:30:
On 2019-01-22 17:09:35 (+0800), Metal A-wing wrote:
On Tue Jan 8 20:19:43 UTC 2019, David Runge wrote: Why is use `$(gem env gemdir)`
Instead of
`$(ruby -e'puts Gem.default_dir')`
It's shorter and you don't have to spawn a ruby process to print something, if you can use the gem command directly.
I'm not a TU so take my this with a grain of salt, but I don't think this is the best advice.
It's shorter, admittedly, but `gem` spawns a ruby process just as
the
`ruby` version does. Using gem doesn't work however when `$GEM_HOME`
is
set, since then it reports the contents of that variable.
Especially for AUR packages using `$(ruby -e'puts Gem.default_dir')`
is
more convenient since most users do not build in a clean chroot, and the wiki actually recommends settings that environment variable so quite
a
few will have it.
Best,
Bert Peters.
Which seems silly and the whole section should be removed in the
first
place. Thats what --user-install switch should be for and that should be default via /etc/gemrc Therefor setting that is just useless fiddling with the system and your gems will be searched there as well as it's default gem path besides /usr/lib.
While `gem` obeys that default, `bundle` (ruby-bundler) does not, and does not have that default, opting for a global install by default. You can override this by manually adding `--path=~/.gem` to every invocation. That's hardly an elegant solution compared to setting an environment variable.
Which is why "bundle config path" exists. A sane way would be to use that to define BUNDLE_PATH in ~/.bundle/config
Fair enough, I did not know about that option. In that case the wiki (and my setup) needs some updating, since it explicitly recommends using GEM_HOME for this. I'll see if I can do something about that tonight.
That said, I'm not convinced there's any harm in using the longer method, since it's slightly more compatible (and technically faster! although not by enough to count it as a benefit). Looking through the community repo both are used.
On 23/1/19 12:11 am, Bert Peters via aur-general wrote:
Levente Polyak via aur-general schreef op 2019-01-22 16:10:
On January 22, 2019 4:03:29 PM GMT+01:00, Bert Peters via aur-general aur-general@archlinux.org wrote:
Levente Polyak via aur-general schreef op 2019-01-22 13:40:
On January 22, 2019 1:25:20 PM GMT+01:00, Bert Peters via aur-general aur-general@archlinux.org wrote:
David Runge schreef op 2019-01-22 12:30:
On 2019-01-22 17:09:35 (+0800), Metal A-wing wrote: > On Tue Jan 8 20:19:43 UTC 2019, David Runge wrote: > Why is use > `$(gem env gemdir)` > > Instead of > > `$(ruby -e'puts Gem.default_dir')` It's shorter and you don't have to spawn a ruby process to print something, if you can use the gem command directly.
I'm not a TU so take my this with a grain of salt, but I don't think this is the best advice.
It's shorter, admittedly, but `gem` spawns a ruby process just as
the
`ruby` version does. Using gem doesn't work however when `$GEM_HOME`
is
set, since then it reports the contents of that variable.
Especially for AUR packages using `$(ruby -e'puts Gem.default_dir')`
is
more convenient since most users do not build in a clean chroot, and the wiki actually recommends settings that environment variable so quite
a
few will have it.
Best,
Bert Peters.
Which seems silly and the whole section should be removed in the
first
place. Thats what --user-install switch should be for and that should be default via /etc/gemrc Therefor setting that is just useless fiddling with the system and your gems will be searched there as well as it's default gem path besides /usr/lib.
While `gem` obeys that default, `bundle` (ruby-bundler) does not, and does not have that default, opting for a global install by default. You can override this by manually adding `--path=~/.gem` to every invocation. That's hardly an elegant solution compared to setting an environment variable.
Which is why "bundle config path" exists. A sane way would be to use that to define BUNDLE_PATH in ~/.bundle/config
Fair enough, I did not know about that option. In that case the wiki (and my setup) needs some updating, since it explicitly recommends using GEM_HOME for this. I'll see if I can do something about that tonight.
That said, I'm not convinced there's any harm in using the longer method, since it's slightly more compatible (and technically faster! although not by enough to count it as a benefit). Looking through the community repo both are used.
If the Environment variable is actually the problem, why not just unset them before proceeding?
unset GEM_HOME
unset BUNDLE_PATH
`$(gem env gemdir)`
Thanks Macca
aur-general@lists.archlinux.org