I am personally confused about what you think the problem is, so I just 
want to make sure that you know that you can develop and test a new 
package, or you can modify an existing package and test the modifications, 
without publishing the package.

Basically in Racket you can:

* create a new package using "raco pkg new", or clone an existing one
* install the package from the local folder, using "raco pkg install 
* make changes and run the tests -- you can keep making changes on the 
installed package without having to re-install it
* once the tests pass, you can commit the changes and publish them

"Under raco pkg management" does not mean that the package is publicly 
available on the racket package server.  You can keep the package private, 
and still be able to install it and run the tests.


On Wednesday, May 27, 2020 at 10:36:10 AM UTC+8, Robert Postill wrote:
> Hi, 
> Inspired by the reply to 
> https://stackoverflow.com/questions/62014612/how-to-test-a-racket-package-self-sufficiently,
>  I 
> decided to ask the question here.  So a little background to the 
> discussion.  I've been looking at a racket package, and the package has a 
> couple of collections.  It's been dormant for a few years, and so when I 
> ran the tests they didn't work (it's a driver, and the database it works 
> with had moved on in the intervening time).  So I started thinking about 
> the tests.  One thing that troubled me was that the tests seemed to be 
> dependant on the package already being installed. Ryan Culpepper's 
> comment on the stack overflow question (
> https://stackoverflow.com/a/62027185/11219) suggests that the tests 
> should be run once the package is under raco pkg's management. Up until 
> that point, I had been considering a PR rewiring the require statements to 
> be significantly more relative.
> In the generally excellent docs for racket, I haven't found advice 
> relating to the right way to structure the tests for a package. Nor an 
> idiomatic approach to dealing with package installation during package 
> development. Here are my sources for reference:
> https://blog.racket-lang.org/2017/10/tutorial-creating-a-package.html
> https://beautifulracket.com/jsonic-3/the-package-server.html
> https://greghendershott.com/2013/12/racket-package-management.html
> http://www.greghendershott.com/2017/04/racket-makefiles.html
> Now I think I should explain why I'm thinking that way.  FYI I've been a 
> part of the ruby community, and so my thinking has a ruby-ish colour.  
> Which makes me think I'm maybe off in my community norms for racket. I've 
> always considered the point at which a package gets transferred into the 
> domain of raco pkg's management to be a pivotal moment. It has this implied 
> social contract that if I'm mixing with code into a system area managed by 
> the language, the package needs to be trustworthy. Testing *after* 
> installing seems a bit like I'm putting the cart before the horse? It feels 
> like saying here's my code, put it in a system-wide place, I hope it works.
> So I'm interested in opinions and advice as to how to think correctly 
> about testing packages and also how other people approach creating a 
> well-behaved package.
> Regards
> Robert

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 

Reply via email to