Declaring the dependencies explicitly is good in a lot of cases, but I
guess there are cases where it is unnecessary.
If you do decide to create the uber package you can create the info.rkt,
`raco pkg install` the package and then use `raco setup --fix-pkg-deps
--unused-pkg-deps ` to let setup
On Saturday, June 20, 2020 at 11:35:32 AM UTC-4, Simon Schlee wrote:
>
>
> What I'd like to do is to create a personal catalog that represents the
>> packages I currently have installed, but it doesn't appear there's a super
>> easy `raco pkg` command to do that - I still need to research a bit.
> What I'd like to do is to create a personal catalog that represents the
> packages I currently have installed, but it doesn't appear there's a super
> easy `raco pkg` command to do that - I still need to research a bit.
>
raco pkg archive --help
Create catalog from installed packages
Usage:
On Fri, Jun 19, 2020 at 01:09:08PM -0700, Brian Adkins wrote:
>
> I'm hoping the main scenario I'm concerned about (a bug is introduced in an
> update of a package) is rare, although that's exactly what motivated Alex
> to create his system. If it is a rare scenario for me, then I'd like to do
On Friday, June 19, 2020 at 3:36:55 PM UTC-4, Hendrik Boom wrote:
>
> On Fri, Jun 19, 2020 at 07:54:29AM -0700, Brian Adkins wrote:
> > On Friday, June 19, 2020 at 8:09:04 AM UTC-4, Neil Van Dyke wrote:
> > >
> > > For an important production system, you probably want the source of
> any
> > >
On Fri, Jun 19, 2020 at 07:54:29AM -0700, Brian Adkins wrote:
> On Friday, June 19, 2020 at 8:09:04 AM UTC-4, Neil Van Dyke wrote:
> >
> > For an important production system, you probably want the source of any
> > third-party packages on which you depend to be in Git (or another SCM
> > system)
On Friday, June 19, 2020 at 8:09:04 AM UTC-4, Neil Van Dyke wrote:
>
> For an important production system, you probably want the source of any
> third-party packages on which you depend to be in Git (or another SCM
> system) that you control.
>
> You might also want to audit those packages yours
For an important production system, you probably want the source of any
third-party packages on which you depend to be in Git (or another SCM
system) that you control.
You might also want to audit those packages yourself, as well as audit
any new version changes to them, before you push to pro
On Thursday, April 30, 2020 at 8:57:45 AM UTC-4, Jay McCarthy wrote:
>
> If you do so, and if your users need to pin themselves to particular
> versions there are broadly two techniques. First, you can create your
> own package catalog. Most users typically use two catalogs: the "big"
> one on p
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
For your second point, you can never really know what other work depends on
your package. You could display a message in the new package or in the
readme for example, but that's likely not going to work well for
various reasons. (but see my last comment)
However, what Jay is saying I believe (corr
On Fri, May 01, 2020 at 06:12:55AM -0700, 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 b
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 ru
Hi Jay,
Thanks for the recap. I suspected that I had enough context,
so it helps to have confirmation from a core dev.
It seems I should leverage a patchwork of sources to support
different use cases.
~slg
‐‐‐ Original Message ‐‐‐
On Thursday, April 30, 2020 8:57 AM, Jay McCarthy
wrot
Hi Sage,
Racket has a very high standard of backwards compatibility where we
strive for programs to work continuously after many many years. In
most cases, we've been able to live up to the standard with the core
pieces of Racket. I can think of only a few times where we broke
compatibility and th
On Wed, Apr 29, 2020 at 12:47 PM Sage Gerard wrote:
> April 9th in the #general Slack channel taught me that there was no clean
> way to
> release a breaking change in a package. I'm open to working on version
> pinning
> support in raco pkg provided that a maintainer can walk me through some
> c
16 matches
Mail list logo
