Skip to content
This repository has been archived by the owner on Feb 28, 2021. It is now read-only.

Adjust project name validations #247

Merged
merged 1 commit into from
Mar 10, 2020
Merged

Conversation

xla
Copy link
Contributor

@xla xla commented Mar 9, 2020

Closes #239 - second part addressing project names.

@xla xla added β1 labels Mar 9, 2020
@xla xla added this to the β1 milestone Mar 9, 2020
@xla xla self-assigned this Mar 9, 2020
@xla xla force-pushed the xla/239-adjust-project-name-validation branch from d7da009 to 693b7c9 Compare March 9, 2020 12:06
core/src/project_name.rs Outdated Show resolved Hide resolved
core/src/ascii32.rs Outdated Show resolved Hide resolved
core/src/ascii32.rs Outdated Show resolved Hide resolved
core/src/ascii32.rs Outdated Show resolved Hide resolved
core/src/ascii32.rs Outdated Show resolved Hide resolved
core/src/lib.rs Outdated Show resolved Hide resolved
core/src/project_name.rs Show resolved Hide resolved
core/src/project_name.rs Show resolved Hide resolved
core/src/project_name.rs Outdated Show resolved Hide resolved
core/src/project_name.rs Outdated Show resolved Hide resolved
core/src/ascii32.rs Outdated Show resolved Hide resolved
@NunoAlexandre
Copy link
Contributor

Btw, @xla, this is a good example of a PR where I'd rather keep some history instead of squashing everything. Please keep at least one commit for the changes around Ascii32 and another for the changes around ProjectName.

@xla xla force-pushed the xla/239-adjust-project-name-validation branch from 5ee4f52 to 1035f98 Compare March 9, 2020 15:20
@xla xla marked this pull request as ready for review March 9, 2020 15:20
fn from_str(s: &str) -> Result<Self, Self::Err> {
Self::from_string(s.to_string())
}
}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's too bad we need both FromStr and TryFrom<&str>

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm honestly curious, why?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They provide different APIS (from_str and try_from("") respectively) I saw a FromStr implementation. It seems the main reason for FromStr being around and distinct from TryFrom<T> is for parse semantics: rust-lang/rfcs#2143 (comment)

I'm not certain about our requirements, but happy to settle on of the methods.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I’d prefer to have one way to do it with TryFrom but I’m ok if we leave it. If we change it here we should align it with the org ID.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did an audit of the codebase for occurrences of from_str and found none. Lo and behold, structopt derivation needs it anyway. I suspect for the parse semantics mentioned above. Will leave it for now and we can revise later.

core/src/project_name.rs Outdated Show resolved Hide resolved
core/src/project_name.rs Outdated Show resolved Hide resolved
Copy link

@cloudhead cloudhead left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couple copy/paste errors but good otherwise!

Copy link
Contributor

@NunoAlexandre NunoAlexandre left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💯

core/src/project_name.rs Outdated Show resolved Hide resolved
core/src/project_name.rs Show resolved Hide resolved
core/src/project_name.rs Outdated Show resolved Hide resolved
core/src/project_name.rs Show resolved Hide resolved
pub fn what(&self) -> &'static str {
""
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we use thiserror here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still need input what we need want and what is possible in the no_std context.

core/src/project_name.rs Outdated Show resolved Hide resolved
@xla xla dismissed CodeSandwich’s stale review March 10, 2020 09:14

Feedback addressed.

@xla xla requested a review from CodeSandwich March 10, 2020 09:14
Copy link

@geigerzaehler geigerzaehler left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM but I haven’t reviewed it thoroughly. There are already three reviewers on this so I’ll leave it to them.

client/examples/project_registration.rs Outdated Show resolved Hide resolved
fn from_str(s: &str) -> Result<Self, Self::Err> {
Self::from_string(s.to_string())
}
}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I’d prefer to have one way to do it with TryFrom but I’m ok if we leave it. If we change it here we should align it with the org ID.

core/src/project_name.rs Outdated Show resolved Hide resolved
Second part of the name validation changes in
radicle-dev/registry-spec#10. Also incorporates the recent addition from
radicle-dev/registry-spec#17. Implementation has been mad symmetrical to
OrgId

Closes #239
@xla xla force-pushed the xla/239-adjust-project-name-validation branch from f5afb76 to 35957cf Compare March 10, 2020 10:21
@xla xla merged commit 32dba53 into master Mar 10, 2020
@xla xla deleted the xla/239-adjust-project-name-validation branch March 10, 2020 10:29
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Adjust OrgId and ProjectName to new required validations
5 participants