On Friday, May 1, 2020 at 9:12:55 PM UTC+8, Jesse Alama wrote:
>
> On Thursday, April 30, 2020 at 2:57:45 PM UTC+2, Jay McCarthy wrote:
>>
>>
>> This is simply a social standard though. There is nothing that
>> technically prevents you from breaking compatibility, except that your
>> users may be upset. You can post things on the package server that
>> follows any rules you want, including conflicting with any other
>> packages.
>>
>
> I'd like to second this point. There's nothing stopping you from pushing
> whatever you want to your repo, and hence distributing whatever you want
> via the package server. I've pushed breaking changes to my packages before,
> and no one has complained, so I guess I didn't break any part of the
> interface that they were using. (Or I have no users of my stuff at all,
> which is certainly possible!)
>
> I don't know how many packages mention, in their description, that they're
> experimental, explicitly warning me that the interface is unstable and
> likely to change. I use 'em anyway because they offer useful functionality.
> I don't recall being nailed by breaking changes, but perhaps I'm just
> getting lucky.
>
> What exactly is the claim, anyway, about the package server not allowing
> breaking changes? Is it that if you do a breaking change to your package,
> then it's possible that other people's packages correspondingly break? If
> so, then I think that's not a very interesting claim. Does the claim at
> issue just amount to a restatement of the ethos that Jay mentioned about
> trying to ensure backwards compatibility for a long time?
>
I think that there are two issues here:
First there's backwards compatibility -- it is a good idea to keep your
packages backwards compatible, although sometimes it can be difficult,
especially with packages which were released too early, before their
interface stabilized.
Than there are breaking changes. This does include the backwards
incompatible changes, but also includes defects. Defects are
unintentional, usually unknown to the author at the time of publishing the
new package version, yet they can break the application.
As an application author, when my application stops working after updating
packages, it is little consolation that the API of a package remained
backwards compatible.
Perhaps I was just unlucky, but I encountered show-stopper defects in the
first two external packages I tried to use in my application. I had a local
fix, but had to wait for the author several months to fix the problem (this
is understandable, the author was busy and these packages were not his top
priority). The mechanism I came up with was driven by the following needs:
(1) sit out a package version because it has a defect
(2) while sitting out a package version, I want to be able to update
other packages that are not affected by the defect
(3) use an alternate source for a package which contains a fix, until
an official fix is released
(4) delay updating packages, until I have time to verify that the
update does not break the application and/or address problems
(5) be able to reconstruct old software configurations including
dependencies
Number (5) is very important to me: I have some development branches which
are active for several months, and when I go bad to an older branch, to
continue work, the last thing I want is to deal with a package upgrade --
this perhaps reflects personal circumstances: I quite often have 1 hour to
try to progress a feature on an old branch, and if I spend 15 - 20 minutes
merging master, updating packages and resolving conflicts, that's 25 - 30%
of available time gone.
> (All this said, I'd like to learn more about setting up custom package
> catalogs, as Alex mentioned, to take matters even more into your own hands.)
>
There is not much to it: git submodules are widely documented, so I'll
leave those out, but here is the script that sets up the package catalog
https://github.com/alex-hhh/ActivityLog2/blob/master/etc/scripts/setup-catalog.sh
And here is the snipped from the build file which sets things up and
installs packages (note that this install uses "isolation mode" to catch
dependencies which are not tracked as submodules, don't use the -i switch
on your development machine):
bash ./etc/scripts/setup-catalog.sh -i pkgs/
raco pkg install --auto tzinfo tzgeolookup data-frame plot-container
I also have added code to my application to verify that the packages are
installed before building or compiling it and it produdces more user
friendly error messages. (e.g. it tells the user that they forgot to
install the "tzinfo" package, rather than failing with a "module not found"
error). You can find that here:
https://github.com/alex-hhh/ActivityLog2/blob/777847f2cdb18ff09596848efc40a332e65da017/rkt/utilities.rkt#L446
Alex.
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-users/a2a706d2-d4fd-4f5a-8e63-7df8af1c6279%40googlegroups.com.
