We should start recommending distro packages (when possible) #29
Comments
|
Added some not so widely used distros, based on my experience. |
|
Reading that person's comments, its seems obvious to me we should be reducing the amount of stuff we offer.
With only 25% of our users using Rakudo Star and with apparent predilection of compiler-only releasers to include zef, I think we should discontinue Rakudo Star by the end of the year and switch to making compiler releases include zef and build Win/macOS binaries. Then, instead of advertising @nxadm repo as a resource of its own, we instead make it a point to ensure that the official™ repos of various distros contain recent-enough packages. So then we get:
Perhaps we should also dial down the frequency of Rakudo releases to once every two months, to offset the extra added work in having to include zef and build binaries. |
And make it a more evidence-based decision, by doing another survey, say, on 1st of October (let it last for a month instead of just a week to gather more responses). |
|
On Wed, 15 Aug 2018, Zoffix Znet wrote:
Reading that person's comments, its seems obvious to me we should be *reducing* the amount of stuff we offer.
- Rakudo compiler-only from github checkout
- Rakudo compiler-only from bash alias
- Rakudo compiler-only from rakudup
- Rakudo compiler-only from tyil's thing whose name I forget
- Rakudo compiler-only from a tarball
- Rakudo compiler-only from a distro repo
- Rakudo compiler-only + zef distro package from a distro repo
- Rakudo compiler-only + zef distro package from nxadm's repo
- Rakudo Star from prebuilt Windows/MacOS binaries
- Rakudo Star from a tarball
- Rakudo Star from docker
- Rakudo Star from chocolatey/homebrew
- Separate NQP/MoarVM releases (or at least rakudo.org lists NQP releases)
With only 25% of our users using Rakudo Star and with apparent
predilection of compiler-only releasers to include zef, I think we should
discontinue Rakudo Star by the end of the year and switch make compiler
releases include zef. Then, instead of advertising @nxadm repo as a
resource of its own, we instead make it a point that the official™ repos
of various distros contain recent-enough packages.
I am sympathetic to dropping Rakudo Star as Rakudo compiler+zef seems to be
no more than a
zef --install
away from being able to run my code.
I am not sure about the included documentation. Some people might use that,
I don't. Perhaps a README with links to the online docu would be sufficient.
So then we get:
- Rakudo compiler-only + zef distro package from a distro repo
- Rakudo compiler-only + zef prebuilt Windows/MacOS binaries
- For packagers/advanced options:
- Rakudo compiler + zef from a github checkout / tarball
- Separate NQP/MoarVM releases (or at least rakudo.org lists NQP releases)
Perhaps we should also dial down the frequency of Rakudo releases to once
every *two* months, to offset the extra added work in having to include
zef and build binaries.
I would, however, prefer to have a monthly release. It is nice to get the
latest improvements (especially performance/stability) quickly. As on Linux
I compile from source anyway, I can do without binaries.
Or would the advanced option "Rakudo compiler + zef from a github checkout /
tarball" be equally "stable" as a "release"?
Just some input from a humble Rakudo user ...
Cheers,
Fritz
…--
Oetiker+Partner AG tel: +41 62 775 9903 (direct)
Fritz Zaucker +41 62 775 9900 (switch board)
Aarweg 15 +41 79 675 0630 (mobile)
CH-4600 Olten fax: +41 62 775 9905
Schweiz web: www.oetiker.ch
|
Responded elsewhere, so we don't stray from the main topic of this Issue. |
|
My Linux packages are the result of regular users using rakudobrew while the devs on the channels felt that, while flexible, it's a dev tool with its own set of problems not intended for end users. Package repository accessible for apt-get and yum are something that people expect nowadays. Personally, I am no longer in a compile-everything-\o/-phase. I would love that the passage of time would render rakudo-pkg obsolete (I am not discussing alternatives in this post), but I see these use cases where the solution above is not a good fit:
The most user friendly scenario in my eyes is providing official rakudo+zef packages like many projects do. If they are self-contained they would not interfere with OS rakudo packages so people would use those if they are recent enough (or for applications packaged by the OS). Once the automation is done, this is not a lot of work. Also, I would warn against putting to much weight on the survey. It's certainly useful, but we have no idea what so ever how representative it is for our user base. Does the participation of core people (or even #perl6 regulars) screws the result? Does a decision we implement for our present user base align with the one in the future? |
|
@nxadm what do you think about appimage and its alternatives? |
The current participation rate in our surveys doesn't cover everyone, for sure, but it's still the largest piece of aggregated community responses we've got to work with. We should definitely use it to get a feel for what the surveyed users want. |
|
Personally I recommend the packages @nxadm puts together to anyone
interested in using Perl6 and keeping up to date.
On Thu, 16 Aug 2018 at 08:39 Benjamin Frady ***@***.***> wrote:
And make it a more evidence-based decision, by doing another survey, say,
on 1st of October (let it last for a month instead of just a week to gather
more responses).
Also, I would warn against putting to much weight on the survey. It's
certainly useful, but we have no idea what so ever how representative it is
for our user base. Does the participation of core people (or even #perl6
regulars) screws the result? Does a decision we implement for our present
user base align with the one in the future?
While yeah, the current participation rate in our surveys doesn't cover
everyone, for sure, it's still the largest piece of aggregated community
responses we've got to work with. We should definitely use it to get a feel
for what the surveyed users want.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#29 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAE87v-v4FmBwRcryWqbTYcf1Pq1Osemks5uRSGbgaJpZM4V9fmU>
.
--
Simon Proctor
Cognoscite aliquid novum cotidie
|
Sounds nifty for some things — portability and whatnot, but I don't think it solves our problem. Rakudo+Zef being available on the centralized all-around-used repositories for each distribution would make more sense to the user in most cases, I'd assume. |
My proposal was under the assumption that distro binaries would have the latest and greatest rakudo + zef package, rendering nxadm's packages obsolete. If distro binaries aren't kept up-to-date, then yeah, there should be the latest-and-greatest distro packages available somewhere. |
|
@AlexDaniel: @samcv experimented with a rakudo appimage. It appeared briefly on Rakudo Star, but it was removed. My view on the portable container packages is that they may be handy for some users, but none of these solutions are used very widely. I also fear that without a relocatable rakudo they are technically not really an option. Furthermore:
C. |
Sadly, LTS distributions will be out-of-date almost by definition. An other way of rendering rakudo-pkg obsolete is by the rakudo org taking them over. |
|
I'm very glad to see that the conversation i started seems to perhaps even lead to something, i knew the language was awesome put it seems like even the community is as well. |
(sparked by this conversation)
Some examples:
Ubuntu
but no zef
Debian
Zef is available in perl6-zef package that is installed automatically when you
apt install perl6(on testing/unstable only).Fedora
Also I found this, are modules already packaged? 😲👍
Arch
Zef seems to be available
Gentoo
Void
… and so on! These are just a few I looked at.
I'm convinced that on many distros installing from repository is the main and preferred way of installing things. If this is already possible for some people, we can start recommending it.
The text was updated successfully, but these errors were encountered: