Re: [racket-users] Should I stop sending packages to the catalog?

2020-06-20 Thread Simon Schlee
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 create the list of 
package dependencies.

-- 
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/8dc1fae7-5f7e-480d-81bf-4aee9ef69d14o%40googlegroups.com.


Re: [racket-users] Should I stop sending packages to the catalog?

2020-06-20 Thread Brian Adkins
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.
>>
>
> raco pkg archive --help
> Create catalog from installed packages
>
> Usage:
> raco pkg archive [  ... ]   [] ...
>  where  is one of
>   --include-deps : Include dependencies of specified packages
> * --exclude  : Exclude  from new catalog
>   --relative : Make source paths relative when possible
>   --help, -h : Show this help
>   -- : Do not treat any remaining argument as a switch (at this level)
>  * Asterisks indicate options allowed multiple times.
>  Multiple single-letter switches can be combined after one `-'; for
>   example: `-h-' is the same as `-h --'
>

Yup. And then either list all the packages individually, or create an uber 
package that lists all the packages individually and archive that. Not very 
convenient, so I may look into adding a flag that creates a catalog from 
*all* of the locally installed packages.

-- 
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/7744719c-b7c2-4a73-9f90-3acc2ce0a0afo%40googlegroups.com.


Re: [racket-users] Should I stop sending packages to the catalog?

2020-06-20 Thread Simon Schlee


> 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:
raco pkg archive [  ... ]   [] ...
 where  is one of
  --include-deps : Include dependencies of specified packages
* --exclude  : Exclude  from new catalog
  --relative : Make source paths relative when possible
  --help, -h : Show this help
  -- : Do not treat any remaining argument as a switch (at this level)
 * Asterisks indicate options allowed multiple times.
 Multiple single-letter switches can be combined after one `-'; for
  example: `-h-' is the same as `-h --'
 

-- 
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/1ce74a5d-ca53-42f6-a83e-666b77d4a4a1o%40googlegroups.com.


Re: [racket-users] Should I stop sending packages to the catalog?

2020-06-19 Thread Hendrik Boom
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 
> the following:
> 
> 1) Develop & test locally while updating packages as needed
> 2) Prior to releasing to production, so *something* that effectively 
> snapshots my environment
> 3) Use the snapshot to deploy to production
> 
> Although I have some ideas about the "something" task, I still have to 
> finalize the procedure and try it out. One option is to simply use a 
> racksnap snapshot. 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. Either there is a command, or it seems like a relatively 
> straightforward thing to add.

Making a complete copy of everything stored under ~/.racket might make 
enough of a racket system snapshot on a GNU/Linux system.  I have no 
idea what to do on Windows, though.

-- hendrik

-- 
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/20200619204945.rj6kckxwmsvutag6%40topoi.pooq.com.


Re: [racket-users] Should I stop sending packages to the catalog?

2020-06-19 Thread Brian Adkins
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 
> > > 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 production. 
> > > 
> > > After you do those things in SCM, depending how you do it, you *might* 
> > > find it's more convenient to simply load the third-party code you need 
> > > using the module system `require` only, without an additional package 
> > > system. 
> > > 
> > 
> > While I see some benefits of this approach, I just looked at a typical 
> > Rails project of mine, and it has over 160 packages with some packages 
> > depending on different versions of other packages, etc., so I think 
> > managing all of this myself in git might be overly burdensome. Granted, 
> my 
> > current Racket apps have far fewer dependencies, but I expect that may 
> > increase over time. 
>
> If you want to avoid problems with software you use changing 
> unpredictably, you will have to have use your own copy that does not 
> change at all. 
>
> I don't see another alternative if your upstream source might change at 
> any time. 
>
> And you will likely have to vet any chaanges that appear upstream in 
> case they actually do fix security-related issues that might already 
> be affect you.  It will be up to you to determine the risks of leaving 
> your local copy unchanged. 
>

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 
the following:

1) Develop & test locally while updating packages as needed
2) Prior to releasing to production, so *something* that effectively 
snapshots my environment
3) Use the snapshot to deploy to production

Although I have some ideas about the "something" task, I still have to 
finalize the procedure and try it out. One option is to simply use a 
racksnap snapshot. 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. Either there is a command, or it seems like a relatively 
straightforward thing to add.

-- 
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/65039c0a-a001-46f6-af24-a9321a5750bao%40googlegroups.com.


Re: [racket-users] Should I stop sending packages to the catalog?

2020-06-19 Thread Hendrik Boom
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) 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 production. 
> >
> > After you do those things in SCM, depending how you do it, you *might* 
> > find it's more convenient to simply load the third-party code you need 
> > using the module system `require` only, without an additional package 
> > system. 
> >
> 
> While I see some benefits of this approach, I just looked at a typical 
> Rails project of mine, and it has over 160 packages with some packages 
> depending on different versions of other packages, etc., so I think 
> managing all of this myself in git might be overly burdensome. Granted, my 
> current Racket apps have far fewer dependencies, but I expect that may 
> increase over time. 

If you want to avoid problems with software you use changing 
unpredictably, you will have to have use your own copy that does not 
change at all.

I don't see another alternative if your upstream source might change at 
any time.

And you will likely have to vet any chaanges that appear upstream in 
case they actually do fix security-related issues that might already 
be affect you.  It will be up to you to determine the risks of leaving 
your local copy unchanged.

-- hendrik

> 
> -- 
> 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/32b8f70a-4033-43db-aca3-b30b9023f3a3o%40googlegroups.com.

-- 
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/20200619193649.ks3gffy7wfggakkg%40topoi.pooq.com.


Re: [racket-users] Should I stop sending packages to the catalog?

2020-06-19 Thread Brian Adkins
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 yourself, as well as audit 
> any new version changes to them, before you push to production. 
>
> After you do those things in SCM, depending how you do it, you *might* 
> find it's more convenient to simply load the third-party code you need 
> using the module system `require` only, without an additional package 
> system. 
>

While I see some benefits of this approach, I just looked at a typical 
Rails project of mine, and it has over 160 packages with some packages 
depending on different versions of other packages, etc., so I think 
managing all of this myself in git might be overly burdensome. Granted, my 
current Racket apps have far fewer dependencies, but I expect that may 
increase over time. 

-- 
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/32b8f70a-4033-43db-aca3-b30b9023f3a3o%40googlegroups.com.


Re: [racket-users] Should I stop sending packages to the catalog?

2020-06-19 Thread Neil Van Dyke
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 production.


After you do those things in SCM, depending how you do it, you *might* 
find it's more convenient to simply load the third-party code you need 
using the module system `require` only, without an additional package 
system.


--
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/3abb676b-a9b2-7578-1246-5e58446faa8d%40neilvandyke.org.


Re: [racket-users] Should I stop sending packages to the catalog?

2020-06-18 Thread Brian Adkins
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 pkgs.racket-lang.org and another "small" one for your 
> particular release, where the core racket packages are pinned to 
> particular versions. When we were designing the package system, we 
> imagined that organizations would maintain their own catalogs of 
> audited versions of packages so they would not be surprised by any 
> automatic updates. Second, you can change your package source to pin 
> to a particular git revision/tag. This might be particularly useful if 
> a package relies on erroneous behavior of some package that was 
> otherwise fixed. 
>

I posted a message in Slack about this also, but in case the mailing list 
is preferred for whoever has the info, I'll post here also.

I'm curious about this approach. The scenario that's important to me is 
being able to control the versions of packages that my app uses. If a 
package is updated, and introduces a bug, I don't want that to cause 
failures in my production app i.e. I want the same set of packages (at 
specific versions) that I'm developing and testing with on my laptop to be 
identical to the ones I will eventually install on my servers at a later 
point in time.

Are people using this approach, described by Jay, of hosting their own 
catalogs, to accomplish this? If so, how do you get setup? In other words, 
how do you populate the catalog with the specific versions of packages you 
want? 

-- 
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/ff40b36c-e868-4844-b147-03d2b796f596o%40googlegroups.com.


Re: [racket-users] Should I stop sending packages to the catalog?

2020-05-01 Thread Alex Harsanyi


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 

Re: [racket-users] Should I stop sending packages to the catalog?

2020-05-01 Thread Laurent
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 (correct me if I'm wrong), is that
you can just create a tag for the previous version, modify your current
package 'my-package' on the pkg server to refer to that tag, and create a
new package 'my-package2' on the pkg server pointing to master. The pkg
catalog is going to be cluttered with all backward-incompatible version
numbers but a) Jay doesn't seem to be worried about that b) it's currently
not the case (meaning, people don't do that currently, but maybe they
should?).

Old users won't see the breaking change, and new users will see and use the
new version on the catalog (or clone directly from github). What's missing
again is a way to tell old users that a new package is available with new
features, but I think Jay was saying some time ago that this should be the
purpose of mailing lists and other media.



On Fri, May 1, 2020 at 2:23 PM Hendrik Boom  wrote:

> 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 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?
> >
> > (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.)
>
> Is there a mechanism for, when you know you are making a breaking change
> in a package, at least being warned about other packages that may break
> as a result?
>
> And is there a mechanism for testing those other packages before
> committing your breaking package to the public repository?
>
> -- hendrik
> >
> > --
> > 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/04ebf61c-54b3-4f58-96aa-f5bdc5f2b457%40googlegroups.com
> .
>
> --
> 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/20200501132344.4nwjgebdlyttwkzu%40topoi.pooq.com
> .
>

-- 
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/CABNTSaGQGFVL%3D4jhaV6WJH6b5QU52rfk-rJ4mbrhvCntO2AZDQ%40mail.gmail.com.


Re: [racket-users] Should I stop sending packages to the catalog?

2020-05-01 Thread Hendrik Boom
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 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?
> 
> (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.)

Is there a mechanism for, when you know you are making a breaking change 
in a package, at least being warned about other packages that may break 
as a result?

And is there a mechanism for testing those other packages before 
committing your breaking package to the public repository?

-- hendrik
> 
> -- 
> 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/04ebf61c-54b3-4f58-96aa-f5bdc5f2b457%40googlegroups.com.

-- 
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/20200501132344.4nwjgebdlyttwkzu%40topoi.pooq.com.


Re: [racket-users] Should I stop sending packages to the catalog?

2020-05-01 Thread Jesse Alama
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?

(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.)

-- 
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/04ebf61c-54b3-4f58-96aa-f5bdc5f2b457%40googlegroups.com.


Re: [racket-users] Should I stop sending packages to the catalog?

2020-04-30 Thread Sage Gerard
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  
wrote:

> 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 they were really traumatic and I think we learned a
> lot from them about what compatibility really means.
>
> The package system reflects this ethos. As you know, you can give a
> dependency a lower-bound, but not an upper-bound, because we have
> always been fairly loose with adding functionality (although it is
> technical backwards incompatible), but not removing functionality. If
> you need to break old programs, then you need to make a new logical
> package, i.e. choose a new name, perhaps by adding a number to your
> old name.
>
> If you need to remove functionality or otherwise break old code, then
> you are not really working on the same package anymore, but a new
> product with similar functionality. In the history of Racket, you can
> see this with the change from `(module _ mzscheme ...)` to `#lang scheme` to 
> `#lang racket` and in the change from `(require mred)` to
> `(require scheme/gui)` to `(require racket/gui)`. These are NOT just
> advertising changes because of new names; instead, the name was a
> result of the need to add or remove functionality, while still
> allowing all old programs to continue working.
>
> 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.
>
> 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 pkgs.racket-lang.org and another "small" one for your
> particular release, where the core racket packages are pinned to
> particular versions. When we were designing the package system, we
> imagined that organizations would maintain their own catalogs of
> audited versions of packages so they would not be surprised by any
> automatic updates. Second, you can change your package source to pin
> to a particular git revision/tag. This might be particularly useful if
> a package relies on erroneous behavior of some package that was
> otherwise fixed.
>
> Jay
>
> 

Re: [racket-users] Should I stop sending packages to the catalog?

2020-04-30 Thread Jay McCarthy
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 they were really traumatic and I think we learned a
lot from them about what compatibility really means.

The package system reflects this ethos. As you know, you can give a
dependency a lower-bound, but not an upper-bound, because we have
always been fairly loose with adding functionality (although it is
technical backwards incompatible), but not removing functionality. If
you need to break old programs, then you need to make a new logical
package, i.e. choose a new name, perhaps by adding a number to your
old name.

If you need to remove functionality or otherwise break old code, then
you are not really working on the same package anymore, but a new
product with similar functionality. In the history of Racket, you can
see this with the change from `(module _ mzscheme ...)` to `#lang
scheme` to `#lang racket` and in the change from `(require mred)` to
`(require scheme/gui)` to `(require racket/gui)`. These are NOT just
advertising changes because of new names; instead, the name was a
result of the need to add or remove functionality, while still
allowing all old programs to continue working.

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.

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 pkgs.racket-lang.org and another "small" one for your
particular release, where the core racket packages are pinned to
particular versions. When we were designing the package system, we
imagined that organizations would maintain their own catalogs of
audited versions of packages so they would not be surprised by any
automatic updates. Second, you can change your package source to pin
to a particular git revision/tag. This might be particularly useful if
a package relies on erroneous behavior of some package that was
otherwise fixed.

Jay

--
Jay McCarthy
Associate Professor @ CS @ UMass Lowell
http://jeapostrophe.github.io
Vincit qui se vincit.

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 code.
>
> In the meantime, as much as I appreciate the efforts made in the current 
> system,
> I'm considering stopping my contributions to the package catalog until 
> further notice.
> I'm open to submitting packages if I am confident in their longevity, but I 
> don't want
> to end up in the position I've been in for the last few weeks when planning a 
> release.
> That position being an inability to release an edition that is not in some 
> way "aware"
> of a prior edition. In my view, changing the package/collection name is an
> example of that problem, not a solution to it.
>
> I'm considering asking my users to specify different package sources in their 
> info.rkt
> files when dealing with my work. Before I commit to that decision, I wanted 
> to tap into
> those of you who have already been here. How have you handled breaking changes
> for your projects? How have you communicated with your users to make sure they
> were adequately prepared? Am I being too black-and-white about this?
>
> ~slg
>
>
> --
> 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/3tKIr3GrU9Jnl7V-5yzb52OL3mjt8XNe9F_Qv9HDKwy8xC4j9lQo2e5eGSle4ZFHAee_FiGVhr15lXoovUE6yqoARP-ZNi3kXXz8ETXdufg%3D%40sagegerard.com.

-- 
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/CAJYbDa%3Dg7xUiAG3ghR1AKRXneUVcY7Q6A4snMiNjNEC12O2P%2Bg%40mail.gmail.com.


Re: [racket-users] Should I stop sending packages to the catalog?

2020-04-29 Thread David Storrs
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
> code.
>
> In the meantime, as much as I appreciate the efforts made in the current
> system,
> I'm considering stopping my contributions to the package catalog until
> further notice.
> I'm open to submitting packages if I am confident in their longevity, but
> I don't want
> to end up in the position I've been in for the last few weeks when
> planning a release.
> That position being an inability to release an edition that is not in some
> way "aware"
> of a prior edition. In my view, changing the package/collection name is an
> example of that problem, not a solution to it.
>
> I'm considering asking my users to specify different package sources in
> their info.rkt
> files when dealing with my work. Before I commit to that decision, I
> wanted to tap into
> those of you who have already been here. How have you handled breaking
> changes
> for your projects? How have you communicated with your users to make sure
> they
> were adequately prepared? Am I being too black-and-white about this?
>
> *~slg*
>

+1 on this.  I'm having the same issue.


>
>
> --
> 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/3tKIr3GrU9Jnl7V-5yzb52OL3mjt8XNe9F_Qv9HDKwy8xC4j9lQo2e5eGSle4ZFHAee_FiGVhr15lXoovUE6yqoARP-ZNi3kXXz8ETXdufg%3D%40sagegerard.com
> 
> .
>

-- 
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/CAE8gKod5udG7pkEcg0yEvDfHuVLXswmDb2jLjG6uWmdvvq9thQ%40mail.gmail.com.


[racket-users] Should I stop sending packages to the catalog?

2020-04-29 Thread Sage Gerard
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 code.

In the meantime, as much as I appreciate the efforts made in the current system,
I'm considering stopping my contributions to the package catalog until further 
notice.
I'm open to submitting packages if I am confident in their longevity, but I 
don't want
to end up in the position I've been in for the last few weeks when planning a 
release.
That position being an inability to release an edition that is not in some way 
"aware"
of a prior edition. In my view, changing the package/collection name is an
example of that problem, not a solution to it.

I'm considering asking my users to specify different package sources in their 
info.rkt
files when dealing with my work. Before I commit to that decision, I wanted to 
tap into
those of you who have already been here. How have you handled breaking changes
for your projects? How have you communicated with your users to make sure they
were adequately prepared? Am I being too black-and-white about this?

~slg

-- 
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/3tKIr3GrU9Jnl7V-5yzb52OL3mjt8XNe9F_Qv9HDKwy8xC4j9lQo2e5eGSle4ZFHAee_FiGVhr15lXoovUE6yqoARP-ZNi3kXXz8ETXdufg%3D%40sagegerard.com.