From 685157a22d5779b358de9f4dead438dfc5b36b6a Mon Sep 17 00:00:00 2001 From: Chris Swindle Date: Tue, 23 May 2017 12:52:26 +0100 Subject: [PATCH 1/7] Initial draft of alternate-registry proposal. --- 0000-template.md | 96 +++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 79 insertions(+), 17 deletions(-) diff --git a/0000-template.md b/0000-template.md index ef898e3360a..139521ee601 100644 --- a/0000-template.md +++ b/0000-template.md @@ -1,47 +1,109 @@ -- Feature Name: (fill me in with a unique ident, my_awesome_feature) -- Start Date: (fill me in with today's date, YYYY-MM-DD) +- Feature Name: alternate-registries +- Start Date: 2017-05-23 - RFC PR: (leave this empty) - Rust Issue: (leave this empty) # Summary [summary]: #summary -One para explanation of the feature. +Adding support for alternative crates.io servers to be used alongside the public crates.io server. # Motivation [motivation]: #motivation -Why are we doing this? What use cases does it support? What is the expected outcome? +Currently cargo only has support for getting crates from a public server, this is fine for +open source projects using Rust, however for closed source code this is problematic. Currently +the only real option is to use Git repositories to specify the packages, but that means that +all of the nice versioning and discoverability that cargo and crates.io provides is lost. I +would like to change this so that it is possible to have a local crates.io server which private +crates can be pushed to, plus still be able to make use of the public crates.io server as well. # Detailed design [design]: #detailed-design -This is the bulk of the RFC. Explain the design in enough detail for somebody familiar -with the language to understand, and for somebody familiar with the compiler to implement. -This should get into specifics and corner-cases, and include examples of how the feature is used. +There are a number of different areas which will likely need to be tackled in order to fully +support a local crates.io server in an enterprise. Below are some key areas: + +* Add support for alternate crates.io registries (this RFC) +* Provide support for caching crates used on a crates.io proxy +* Add support to crates.io to allow authentication with other OAuth providers than github +* Support for private storage of crates on crates.io server rather than publicly available on S3 + +Rather than trying to get everything agreed in a single RFC I would like for these to be +dealt with as separate proposals and use this RFC as a stepping stone to be able to +meaningfully start to use private registries. + +See https://github.com/rust-lang/cargo/pull/4036 for the code changes which this proposal was based on. + +## Cargo.toml config changes +The following changes for Cargo.toml are proposed as part of this RFC: +* Add an optional 'registry' field to be specified as part of the package dependencies +* Add an optional 'registry' field to be specified in the package definition + +Both of the registry entries take a value of a crates.io git repository. If one is not +provided then the default crates.io repository is assumed, this ensures that it is +back compatible with all current crates. + +Below is an example of the change that we are proposing to make: + +``` +[package] +name = "registry-test" +version = "0.1.0" +authors = ["Christopher Swindle "] +registry = "https://github.com/my_awesome_fork/crates.io-index" + +[dependencies] +libc = { version = "*", registry = "https://github.com/my_awesome_fork/crates.io-index" } +serde_json = "1.0.1" +``` + +## Changes for alternative registries for dependencies +This boils down to a very simple change, where we previously setup the crate source for the +crates.io registry, we now just need to check if a registry is provided, if it has the crate +source is created using the registry URL, otherwise the crates.io server is used. + +## Blocking requests to push to a registry +There are two parts to this, the first is a change to Cargo which checks if the registry +provided in the registry matches the host for the publish, if it does not it gets rejected. +The second part is a change to crates.io which will just reject the request to publish the +crate if the configured repository on the crates.io server does not match the registry +specified in the package or dependencies. + +## Allow publishing when referencing external dependencies +We still want to support private crates having dependencies on the public crates.io server, +so we propose relaxing a check which ensures that the source for a dependency matches the +registry. We propose that this only performs the check only if the dependency is not the +default registry, thus allowing private crates to reference public crates on crates.io. # How We Teach This [how-we-teach-this]: #how-we-teach-this -What names and terminology work best for these concepts and why? -How is this idea best presented—as a continuation of existing Rust patterns, or as a wholly new one? +The term alternative registry would seem the most appropriate to describe this feature. -Would the acceptance of this proposal change how Rust is taught to new users at any level? -How should this feature be introduced and taught to existing Rust users? - -What additions or changes to the Rust Reference, _The Rust Programming Language_, and/or _Rust by Example_ does it entail? +In the first instance I think that the Cargo.toml format documentation is sufficient to +provide access to the feature. However, in time once more of the pieces fall into place +it would be useful having a guide on how to setup/administer a crates.io server in an +enterprise setting (similar to the initial mirroring documentation). # Drawbacks [drawbacks]: #drawbacks -Why should we *not* do this? +Currently this design requires that when you want to push to the private crates.io server +you need to override the host and token, it would be possible to update cargo to support +multiple registries tokens which can be used to login. # Alternatives [alternatives]: #alternatives -What other designs have been considered? What is the impact of not doing this? +## Using a single server for cache and private registry +It was considered proposing a single crates.io server which performs both caching of crates.io, +plus has the ability to have crates pushed to it, however this has the following drawbacks: +* It requires crates.io to be able to combine two registries, or requires a radical change to the way crates.io works +* The current proposal could be extended to support this, if a caching server is added at a later stage # Unresolved questions [unresolved]: #unresolved-questions - -What parts of the design are still TBD? +As mentioned in the design section, this does not answer all of the questions for +supporting a private crates.io server, but it provides the first steps in that +direction, with the remaining areas considered out of scope for this RFC. From 4d08fc262c9abea8403608d0d9ee63df23816826 Mon Sep 17 00:00:00 2001 From: Chris Swindle Date: Tue, 23 May 2017 13:09:14 +0100 Subject: [PATCH 2/7] Sort out using a new file for the proposal. --- 0000-template.md | 96 +++++--------------------- text/0000-alternate-registries.md | 109 ++++++++++++++++++++++++++++++ 2 files changed, 126 insertions(+), 79 deletions(-) create mode 100644 text/0000-alternate-registries.md diff --git a/0000-template.md b/0000-template.md index 139521ee601..ef898e3360a 100644 --- a/0000-template.md +++ b/0000-template.md @@ -1,109 +1,47 @@ -- Feature Name: alternate-registries -- Start Date: 2017-05-23 +- Feature Name: (fill me in with a unique ident, my_awesome_feature) +- Start Date: (fill me in with today's date, YYYY-MM-DD) - RFC PR: (leave this empty) - Rust Issue: (leave this empty) # Summary [summary]: #summary -Adding support for alternative crates.io servers to be used alongside the public crates.io server. +One para explanation of the feature. # Motivation [motivation]: #motivation -Currently cargo only has support for getting crates from a public server, this is fine for -open source projects using Rust, however for closed source code this is problematic. Currently -the only real option is to use Git repositories to specify the packages, but that means that -all of the nice versioning and discoverability that cargo and crates.io provides is lost. I -would like to change this so that it is possible to have a local crates.io server which private -crates can be pushed to, plus still be able to make use of the public crates.io server as well. +Why are we doing this? What use cases does it support? What is the expected outcome? # Detailed design [design]: #detailed-design -There are a number of different areas which will likely need to be tackled in order to fully -support a local crates.io server in an enterprise. Below are some key areas: - -* Add support for alternate crates.io registries (this RFC) -* Provide support for caching crates used on a crates.io proxy -* Add support to crates.io to allow authentication with other OAuth providers than github -* Support for private storage of crates on crates.io server rather than publicly available on S3 - -Rather than trying to get everything agreed in a single RFC I would like for these to be -dealt with as separate proposals and use this RFC as a stepping stone to be able to -meaningfully start to use private registries. - -See https://github.com/rust-lang/cargo/pull/4036 for the code changes which this proposal was based on. - -## Cargo.toml config changes -The following changes for Cargo.toml are proposed as part of this RFC: -* Add an optional 'registry' field to be specified as part of the package dependencies -* Add an optional 'registry' field to be specified in the package definition - -Both of the registry entries take a value of a crates.io git repository. If one is not -provided then the default crates.io repository is assumed, this ensures that it is -back compatible with all current crates. - -Below is an example of the change that we are proposing to make: - -``` -[package] -name = "registry-test" -version = "0.1.0" -authors = ["Christopher Swindle "] -registry = "https://github.com/my_awesome_fork/crates.io-index" - -[dependencies] -libc = { version = "*", registry = "https://github.com/my_awesome_fork/crates.io-index" } -serde_json = "1.0.1" -``` - -## Changes for alternative registries for dependencies -This boils down to a very simple change, where we previously setup the crate source for the -crates.io registry, we now just need to check if a registry is provided, if it has the crate -source is created using the registry URL, otherwise the crates.io server is used. - -## Blocking requests to push to a registry -There are two parts to this, the first is a change to Cargo which checks if the registry -provided in the registry matches the host for the publish, if it does not it gets rejected. -The second part is a change to crates.io which will just reject the request to publish the -crate if the configured repository on the crates.io server does not match the registry -specified in the package or dependencies. - -## Allow publishing when referencing external dependencies -We still want to support private crates having dependencies on the public crates.io server, -so we propose relaxing a check which ensures that the source for a dependency matches the -registry. We propose that this only performs the check only if the dependency is not the -default registry, thus allowing private crates to reference public crates on crates.io. +This is the bulk of the RFC. Explain the design in enough detail for somebody familiar +with the language to understand, and for somebody familiar with the compiler to implement. +This should get into specifics and corner-cases, and include examples of how the feature is used. # How We Teach This [how-we-teach-this]: #how-we-teach-this -The term alternative registry would seem the most appropriate to describe this feature. +What names and terminology work best for these concepts and why? +How is this idea best presented—as a continuation of existing Rust patterns, or as a wholly new one? -In the first instance I think that the Cargo.toml format documentation is sufficient to -provide access to the feature. However, in time once more of the pieces fall into place -it would be useful having a guide on how to setup/administer a crates.io server in an -enterprise setting (similar to the initial mirroring documentation). +Would the acceptance of this proposal change how Rust is taught to new users at any level? +How should this feature be introduced and taught to existing Rust users? + +What additions or changes to the Rust Reference, _The Rust Programming Language_, and/or _Rust by Example_ does it entail? # Drawbacks [drawbacks]: #drawbacks -Currently this design requires that when you want to push to the private crates.io server -you need to override the host and token, it would be possible to update cargo to support -multiple registries tokens which can be used to login. +Why should we *not* do this? # Alternatives [alternatives]: #alternatives -## Using a single server for cache and private registry -It was considered proposing a single crates.io server which performs both caching of crates.io, -plus has the ability to have crates pushed to it, however this has the following drawbacks: -* It requires crates.io to be able to combine two registries, or requires a radical change to the way crates.io works -* The current proposal could be extended to support this, if a caching server is added at a later stage +What other designs have been considered? What is the impact of not doing this? # Unresolved questions [unresolved]: #unresolved-questions -As mentioned in the design section, this does not answer all of the questions for -supporting a private crates.io server, but it provides the first steps in that -direction, with the remaining areas considered out of scope for this RFC. + +What parts of the design are still TBD? diff --git a/text/0000-alternate-registries.md b/text/0000-alternate-registries.md new file mode 100644 index 00000000000..139521ee601 --- /dev/null +++ b/text/0000-alternate-registries.md @@ -0,0 +1,109 @@ +- Feature Name: alternate-registries +- Start Date: 2017-05-23 +- RFC PR: (leave this empty) +- Rust Issue: (leave this empty) + +# Summary +[summary]: #summary + +Adding support for alternative crates.io servers to be used alongside the public crates.io server. + +# Motivation +[motivation]: #motivation + +Currently cargo only has support for getting crates from a public server, this is fine for +open source projects using Rust, however for closed source code this is problematic. Currently +the only real option is to use Git repositories to specify the packages, but that means that +all of the nice versioning and discoverability that cargo and crates.io provides is lost. I +would like to change this so that it is possible to have a local crates.io server which private +crates can be pushed to, plus still be able to make use of the public crates.io server as well. + +# Detailed design +[design]: #detailed-design + +There are a number of different areas which will likely need to be tackled in order to fully +support a local crates.io server in an enterprise. Below are some key areas: + +* Add support for alternate crates.io registries (this RFC) +* Provide support for caching crates used on a crates.io proxy +* Add support to crates.io to allow authentication with other OAuth providers than github +* Support for private storage of crates on crates.io server rather than publicly available on S3 + +Rather than trying to get everything agreed in a single RFC I would like for these to be +dealt with as separate proposals and use this RFC as a stepping stone to be able to +meaningfully start to use private registries. + +See https://github.com/rust-lang/cargo/pull/4036 for the code changes which this proposal was based on. + +## Cargo.toml config changes +The following changes for Cargo.toml are proposed as part of this RFC: +* Add an optional 'registry' field to be specified as part of the package dependencies +* Add an optional 'registry' field to be specified in the package definition + +Both of the registry entries take a value of a crates.io git repository. If one is not +provided then the default crates.io repository is assumed, this ensures that it is +back compatible with all current crates. + +Below is an example of the change that we are proposing to make: + +``` +[package] +name = "registry-test" +version = "0.1.0" +authors = ["Christopher Swindle "] +registry = "https://github.com/my_awesome_fork/crates.io-index" + +[dependencies] +libc = { version = "*", registry = "https://github.com/my_awesome_fork/crates.io-index" } +serde_json = "1.0.1" +``` + +## Changes for alternative registries for dependencies +This boils down to a very simple change, where we previously setup the crate source for the +crates.io registry, we now just need to check if a registry is provided, if it has the crate +source is created using the registry URL, otherwise the crates.io server is used. + +## Blocking requests to push to a registry +There are two parts to this, the first is a change to Cargo which checks if the registry +provided in the registry matches the host for the publish, if it does not it gets rejected. +The second part is a change to crates.io which will just reject the request to publish the +crate if the configured repository on the crates.io server does not match the registry +specified in the package or dependencies. + +## Allow publishing when referencing external dependencies +We still want to support private crates having dependencies on the public crates.io server, +so we propose relaxing a check which ensures that the source for a dependency matches the +registry. We propose that this only performs the check only if the dependency is not the +default registry, thus allowing private crates to reference public crates on crates.io. + +# How We Teach This +[how-we-teach-this]: #how-we-teach-this + +The term alternative registry would seem the most appropriate to describe this feature. + +In the first instance I think that the Cargo.toml format documentation is sufficient to +provide access to the feature. However, in time once more of the pieces fall into place +it would be useful having a guide on how to setup/administer a crates.io server in an +enterprise setting (similar to the initial mirroring documentation). + +# Drawbacks +[drawbacks]: #drawbacks + +Currently this design requires that when you want to push to the private crates.io server +you need to override the host and token, it would be possible to update cargo to support +multiple registries tokens which can be used to login. + +# Alternatives +[alternatives]: #alternatives + +## Using a single server for cache and private registry +It was considered proposing a single crates.io server which performs both caching of crates.io, +plus has the ability to have crates pushed to it, however this has the following drawbacks: +* It requires crates.io to be able to combine two registries, or requires a radical change to the way crates.io works +* The current proposal could be extended to support this, if a caching server is added at a later stage + +# Unresolved questions +[unresolved]: #unresolved-questions +As mentioned in the design section, this does not answer all of the questions for +supporting a private crates.io server, but it provides the first steps in that +direction, with the remaining areas considered out of scope for this RFC. From 9a35536ab0244d73f96e25bbf8409b09a82127c7 Mon Sep 17 00:00:00 2001 From: Chris Swindle Date: Tue, 23 May 2017 15:18:14 +0100 Subject: [PATCH 3/7] Update to include changes to an alternate crates.io registry to include the registry in Cargo.toml fragment. --- text/0000-alternate-registries.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/text/0000-alternate-registries.md b/text/0000-alternate-registries.md index 139521ee601..0179799ea1c 100644 --- a/text/0000-alternate-registries.md +++ b/text/0000-alternate-registries.md @@ -76,6 +76,11 @@ so we propose relaxing a check which ensures that the source for a dependency ma registry. We propose that this only performs the check only if the dependency is not the default registry, thus allowing private crates to reference public crates on crates.io. +## Making it easier for users using an alternate crates.io registry +When a user selects a specific crate the Cargo.toml fragment would be updated to include the +registry URL, thus allowing users to easily copy and paste into their projects Cargo.toml +file. + # How We Teach This [how-we-teach-this]: #how-we-teach-this @@ -102,6 +107,12 @@ plus has the ability to have crates pushed to it, however this has the following * It requires crates.io to be able to combine two registries, or requires a radical change to the way crates.io works * The current proposal could be extended to support this, if a caching server is added at a later stage +## Including registry definitions in a global location +We considered using a global configuration file (eg ~/.cargo/config) to allow a registry to +be specified, however this was ruled out on the basis that we believe that the registry to +use for dependencies is tightly linked to the project and hence it would be wrong to move +this into global configuration. + # Unresolved questions [unresolved]: #unresolved-questions As mentioned in the design section, this does not answer all of the questions for From 106440f7dd8dd2247bf10a264fccb5ff282b2e59 Mon Sep 17 00:00:00 2001 From: Chris Swindle Date: Thu, 25 May 2017 06:38:37 +0100 Subject: [PATCH 4/7] Add section on dependency resolution, plus crate naming. --- text/0000-alternate-registries.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) mode change 100644 => 100755 text/0000-alternate-registries.md diff --git a/text/0000-alternate-registries.md b/text/0000-alternate-registries.md old mode 100644 new mode 100755 index 0179799ea1c..9fc63267282 --- a/text/0000-alternate-registries.md +++ b/text/0000-alternate-registries.md @@ -58,6 +58,22 @@ libc = { version = "*", registry = "https://github.com/my_awesome_fork/crates.io serde_json = "1.0.1" ``` +## Dependency resolution +This RFC proposes going to an alternative registry for a dependency only if the registry key +is present in the dependency. This means that in situations where there is the same name +crate on both crates.io and the alternate registry, if no registry is provided it will +use the one from crates.io. There are valid situations where people may wish to override +a particular crate with an alternate one, however the existing source replacement feature +seems a better fit to solve that scenario. + +## Crate naming on alternate servers +It would be sensible, on an alternate server, for users not to publish using the same +name as a public crate as that will cause issues if someone need to use a public and private +crate with the same name. In order to minimise the risk of this happening I propose +that an optional field is added to the crates.io config which allows a prefix to be configured, +when a crate is published, the prefix is checked and the request rejected with a sensible error +if the crate name does not match. + ## Changes for alternative registries for dependencies This boils down to a very simple change, where we previously setup the crate source for the crates.io registry, we now just need to check if a registry is provided, if it has the crate From ddddb743fa1be7e888df186b7db8791342f2211d Mon Sep 17 00:00:00 2001 From: Chris Swindle Date: Tue, 20 Jun 2017 21:46:28 +0100 Subject: [PATCH 5/7] Adding information about git index file changes. --- text/0000-alternate-registries.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/text/0000-alternate-registries.md b/text/0000-alternate-registries.md index 9fc63267282..a85183cd16e 100755 --- a/text/0000-alternate-registries.md +++ b/text/0000-alternate-registries.md @@ -79,6 +79,15 @@ This boils down to a very simple change, where we previously setup the crate sou crates.io registry, we now just need to check if a registry is provided, if it has the crate source is created using the registry URL, otherwise the crates.io server is used. +### Index files changes +As Cargo requires the index file to include all the dependencies, the crates.io index file +format is updated to include the registry in the dependency. The registry is an optional field, +where by default it is None, and will only be set when using an alternate crate server. + +Validation of the depdencies on crates.io is also updated so that local registry crates are +checked for their existance on the local registry, they will not however validate any +external dependencies, instead they will be assumed to be valid. + ## Blocking requests to push to a registry There are two parts to this, the first is a change to Cargo which checks if the registry provided in the registry matches the host for the publish, if it does not it gets rejected. @@ -129,6 +138,13 @@ be specified, however this was ruled out on the basis that we believe that the r use for dependencies is tightly linked to the project and hence it would be wrong to move this into global configuration. +## Validating external dependencies +It would be possible to check that external dependencies exist, however I think that this +would need to be optional as there could be situations where the alternate crates.io +server would be unable to contact the external dependencies and hence would not be +possible. This is certainly something that could be added at a later stage if there is +sufficient demand. + # Unresolved questions [unresolved]: #unresolved-questions As mentioned in the design section, this does not answer all of the questions for From e2eac449640212838203e9661a1512f657ccf05d Mon Sep 17 00:00:00 2001 From: Chris Swindle Date: Mon, 3 Jul 2017 22:50:25 +0100 Subject: [PATCH 6/7] Updating with changes suggested by @alexcrichton and @carols10cents. --- text/0000-alternate-registries.md | 39 ++++++++++++++++++++++--------- 1 file changed, 28 insertions(+), 11 deletions(-) diff --git a/text/0000-alternate-registries.md b/text/0000-alternate-registries.md index a85183cd16e..7fa630f2649 100755 --- a/text/0000-alternate-registries.md +++ b/text/0000-alternate-registries.md @@ -40,8 +40,8 @@ The following changes for Cargo.toml are proposed as part of this RFC: * Add an optional 'registry' field to be specified as part of the package dependencies * Add an optional 'registry' field to be specified in the package definition -Both of the registry entries take a value of a crates.io git repository. If one is not -provided then the default crates.io repository is assumed, this ensures that it is +Both of the registry entries take a value of a crates.io web server. If one is not +provided then the default crates.io URL is assumed, this ensures that it is back compatible with all current crates. Below is an example of the change that we are proposing to make: @@ -51,13 +51,26 @@ Below is an example of the change that we are proposing to make: name = "registry-test" version = "0.1.0" authors = ["Christopher Swindle "] -registry = "https://github.com/my_awesome_fork/crates.io-index" +registry = "https://www.my_awesome_fork.com/" [dependencies] -libc = { version = "*", registry = "https://github.com/my_awesome_fork/crates.io-index" } +libc = { version = "*", registry = "https://www.my_awesome_fork.com/" } serde_json = "1.0.1" ``` +## Mapping Between Registry and Git Repository +Currently the Git repository is used internally within Cargo, in order for Cargo to map +between the servers URL and a Git respository for the crates.io web server, the server +exposes a set endpoint which provides the Git repository to use, for example: + +``` + http://crates.io/git +``` + +This will just return the Git repository to use, which the server already knows. When cargo +needs to perform an action on an alternate registry it just performs a GET request +on the URL and then uses the Git repository returned. + ## Dependency resolution This RFC proposes going to an alternative registry for a dependency only if the registry key is present in the dependency. This means that in situations where there is the same name @@ -82,18 +95,20 @@ source is created using the registry URL, otherwise the crates.io server is used ### Index files changes As Cargo requires the index file to include all the dependencies, the crates.io index file format is updated to include the registry in the dependency. The registry is an optional field, -where by default it is None, and will only be set when using an alternate crate server. +where by default it is None, and will only be set when using an alternate crate server. The +official public crates.io server will block any publish requests which contain a registry +in dependencies, so for crates.io this will always be set to None. Validation of the depdencies on crates.io is also updated so that local registry crates are checked for their existance on the local registry, they will not however validate any external dependencies, instead they will be assumed to be valid. ## Blocking requests to push to a registry -There are two parts to this, the first is a change to Cargo which checks if the registry -provided in the registry matches the host for the publish, if it does not it gets rejected. -The second part is a change to crates.io which will just reject the request to publish the -crate if the configured repository on the crates.io server does not match the registry -specified in the package or dependencies. +Cargo will by try and publish to the registry that is provided in the Cargo.toml (if one is +provided), if the registry has been override and it does not match the entry in Cargo.toml it will +be rejected. The second part is a change to crates.io which will just reject the request to +publish the crate if the configured registry on the crates.io server does not match the +registry specified in the package or dependencies. ## Allow publishing when referencing external dependencies We still want to support private crates having dependencies on the public crates.io server, @@ -104,7 +119,9 @@ default registry, thus allowing private crates to reference public crates on cra ## Making it easier for users using an alternate crates.io registry When a user selects a specific crate the Cargo.toml fragment would be updated to include the registry URL, thus allowing users to easily copy and paste into their projects Cargo.toml -file. +file. Below is an example of how this might look: + +Example layout of crates.io with URL in fragment # How We Teach This [how-we-teach-this]: #how-we-teach-this From e61c4cb239bb2bd55a8cc4ad118f53db076681d3 Mon Sep 17 00:00:00 2001 From: Chris Swindle Date: Fri, 11 Aug 2017 15:15:40 +0100 Subject: [PATCH 7/7] Adding information about requiring unstable features in cargo, plus registry public API. --- text/0000-alternate-registries.md | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/text/0000-alternate-registries.md b/text/0000-alternate-registries.md index 7fa630f2649..3cc82ec87db 100755 --- a/text/0000-alternate-registries.md +++ b/text/0000-alternate-registries.md @@ -164,6 +164,11 @@ sufficient demand. # Unresolved questions [unresolved]: #unresolved-questions -As mentioned in the design section, this does not answer all of the questions for -supporting a private crates.io server, but it provides the first steps in that -direction, with the remaining areas considered out of scope for this RFC. +As mentioned in the design section, this RFC does not answer all of the questions for +supporting a private crates.io server, but it provides the first steps in that direction, +with the remaining areas considered out of scope for this RFC. However, the following issues +will need to be solved before this RFC can be fully implemented, although not +necessarily directly as part of this RFC: + +* There needs to be a mechanism for unstable features in cargo +* A public API needs to be available for the registry format prior to this feature being available in stable builds