> In the context of packages, does it make sense to refer to a package
> name without a major version number, given that major versions are
> incompatible?
>
> I think the reasons we have to refer to package names would all require
> a major version, and so I agree with the way the current design s
At Thu, 2 May 2013 10:20:09 -0400, Walter Tetzner wrote:
> On Tue, Apr 30, 2013 at 12:24 PM, Matthew Flatt wrote:
> > 2. It could mean that the package system has a built-in way to declare
> > dependencies not only on a particular package, but on a particular
> > revision of a package ---
Interesting!
On Thu, May 2, 2013 at 4:20 PM, Jay McCarthy wrote:
> On Thu, May 2, 2013 at 8:18 AM, Laurent wrote:
> > Does this mean that if I include a test suite in my package and register
> it
> > on PLaneT, the tests will be automatically run from your servers?
>
> If you put a test suite
On Thu, May 2, 2013 at 8:18 AM, Laurent wrote:
> Does this mean that if I include a test suite in my package and register it
> on PLaneT, the tests will be automatically run from your servers?
If you put a test suite in your package and register it on our
catalog, and your package is ring 0, then
On Tue, Apr 30, 2013 at 12:24 PM, Matthew Flatt wrote:
> 2. It could mean that the package system has a built-in way to declare
> dependencies not only on a particular package, but on a particular
> revision of a package --- either to ensure that certain features
> are available or th
Does this mean that if I include a test suite in my package and register it
on PLaneT, the tests will be automatically run from your servers?
And if some test fails, the package will not be updated for those who run
`raco pkg update` ?
On Thu, May 2, 2013 at 4:11 PM, Robby Findler
wrote:
> One t
Yes, this curation system is already partially in place. When you go
to the main catalog, you'll see that each package has a 'ring' number
where 0 = trusted, 1 = non conflicting, 2 = unknown. I have not yet
set up continuous integration of ring 0, but I will soon. Also, I
haven't got the documentat
One thing perhaps worth mentioning, tho, is that there will be a curated
package source where we will make significant efforts to avoid "accidental"
bugs like this, by automatically running test suites, etc. Something much
like the process that we use for Racket's git (except that in the case of
Ra
On Thu, May 2, 2013 at 7:29 AM, Matthew Flatt wrote:
> [Jay will have to correct me if I have any part of this wrong...]
Nope, it was beautiful.
> At Thu, 2 May 2013 11:31:09 +0200, Laurent wrote:
> As an aside, the `raco pkg update' action is not restricted to packages
> installed by package na
That sounds all good to me! Thanks!
On Thu, May 2, 2013 at 3:29 PM, Matthew Flatt wrote:
> [Jay will have to correct me if I have any part of this wrong...]
>
> At Thu, 2 May 2013 11:31:09 +0200, Laurent wrote:
> > Say I want to use a package, registered on the PLaneT catalog as X.
> > First I
[Jay will have to correct me if I have any part of this wrong...]
At Thu, 2 May 2013 11:31:09 +0200, Laurent wrote:
> Say I want to use a package, registered on the PLaneT catalog as X.
> First I do `raco pkg install X`.
Yes.
> In my Racket files, I simply use `(require X)'.
Assuming that packa
On 04/30/2013 12:24 PM, Matthew Flatt wrote:
I have been working with Jay on the package manager recently, and so I
have some further info on this point.
snip
In particular, I can imagine having a project whose source code
includes a package catalog. To upgrade a particular package, I'd change
At Tue, 9 Apr 2013 18:18:35 +0200, Berthold Bäuml wrote:
> I hope to find time to write up the model this weekend. But what is
> absolutely clear to us is that a package management system has to
> have a notion of versions (or variants as I called them) for a
> package at the lowest level -- otherw
In my experience Planet 1 makes introducing a new version enough of an
effort that you're not inclined to do it casually. As a result,
there's a tendency for changes to accumulate on (say) GitHub, before
getting rolled up into a Planet update. At least that's what I found
myself doing.
With the ne
>
>> on top of such a low level system one can add more convenient interfaces for
>> users for the more standard use cases, e.g., mimicking the version
>> disregarding behavior of planet2 -- but it is not possible to do it the
>> other way round.
>
>
> Are you sure? You can add commands to
On Apr 9, 2013, at 12:18 PM, Berthold Bäuml wrote:
> on top of such a low level system one can add more convenient interfaces for
> users for the more standard use cases, e.g., mimicking the version
> disregarding behavior of planet2 -- but it is not possible to do it the other
> way round.
On 09.04.2013, at 16:11, Matthias Felleisen wrote:
>
> On Apr 8, 2013, at 6:03 PM, Berthold Bäuml wrote:
>
>> Another interesting model for package management (even including, e.g., how
>> to check out and commit packages during development) has emerged over the
>> last years in our field
On Apr 8, 2013, at 6:03 PM, Berthold Bäuml wrote:
> Another interesting model for package management (even including, e.g., how
> to check out and commit packages during development) has emerged over the
> last years in our field of research with the open source ROS (robot operating
> system
On 04.04.2013, at 17:09, Jay McCarthy wrote:
> On Thu, Apr 4, 2013 at 8:58 AM, Laurent wrote:
>> Some questions about Planet 2, using github, but not really used to it.
>
> I think these questions are about the Racket package system, since I
> don't know what "Planet 2" is, so I'll answer them
The new package system is very different than Planet. Planet will
continued to be supported. You don't need to use the new one.
The new package system does not have "internal" linking like Planet,
so your program might be:
(require memoize)
(require graph/dijkstra)
if those packages were convert
If I am a consumer of packages do I need to make any changes to use the new
system?
For example, I have code that has:
(require (planet dherman/memoize:3:1))
(require (planet jaymccarthy/dijkstra:1:2))
What do I do to "point" at planet2?
Thanks,
-joe
On Thu, Apr 4, 2013 at 8:18 AM, Jay McCart
In general, the new package system is designed for developers to only
interact with the PNR a single time, to create the package, and never
again. This is why it leverages git/etc so that their normal processes
are "just right".
Since creating an incompatible change creates a "new" package, I thin
> > But I see that many packages on Planet2 are using the master as the
> package
> > source. Then how do the developers manage major versions and development?
>
> I believe that most of these developers do not intend to ever break
> compatibility. But if they do, they can tag the last "Version 1"
On Thu, Apr 4, 2013 at 8:58 AM, Laurent wrote:
> Some questions about Planet 2, using github, but not really used to it.
I think these questions are about the Racket package system, since I
don't know what "Planet 2" is, so I'll answer them. :)
> * Currently, the main files of my projects are at
Some questions about Planet 2, using github, but not really used to it.
* Currently, the main files of my projects are at the root of the git repo.
IIUC, Planet2 requires them to be in a subdirectory of the git repo, so as
to be considered as a collection by Racket, is that correct?
Then where wi
25 matches
Mail list logo
