gankra / cargo-mommy Goto Github PK

mommy tries to copy itself to the same directory it's already in when using "i mean", but this won't work when it doesn't have permission to write to that directory (most notably, when installed via Nix). I should be able to tell mommy what directory to use for aliases (e.g. with an env var).

Also I noticed mommy copies her binary instead of symlinking. That seems like it will cause trouble when updating mommy.

mew, not sure if it's abdl or plurality related (or both) but wei have multiple littles sometimes blending at the same time. would a pull request for multiple littles be welcome? also our caregiver also needs support sometime.

Might fork it for maintaining it,
i am new to git so i might need some help.
https://github.com/lukas-the-wizard/cargo-mommy-ce

Anyone who wants to help and do this, reply.
I am not interested in doing duplicate work, so if @Gankra continues here, i might stop mine and commit here.

thanks for reading

PS: also my social, so you know who I am: https://tech.lgbt/@lukasfr

I know it's rude to ask mommy how old she is, but I'd like a way to ask her what her version is (and maybe a list of her moods).

Project license is specified as MIT in Cargo.toml:

But LICENSE file is not present in the repository. You might consider adding it.

If you use the i mean feature to convert mommy into a binary which has a space in its name, it will correctly infer the correct role up to the point where it needs to find the names of environment variables to fetch information from.

In a hypothetical scenario, I was able to have it spit this:

/ ~ cargo mommy i mean "big sis"
mommy is now big sis~
/ ~ CARGO_BIG_SISS_LITTLE=TEST cargo "big sis" --help
[ SNIP ]
SCREAMING_ROLE: BIG SIS
SCREAMING_ROLE: BIG SIS
SCREAMING_ROLE: BIG SIS
SCREAMING_ROLE: BIG SIS
SCREAMING_ROLE: BIG SIS
big sis loves her cute little girl~ 💗

IMO, the correct behaviour should be that spaces be replaced with "_" when converting to screaming_role.

I'm not 100% sure how i'd want it to be impl the interface for it, but some people are concerned about the more spicy mood strings being in the binary, so it would be nice to have a way to maybe do like --no-default-features and have only chill mode.

The only place that really needs to change is here:

https://github.com/Gankra/cargo-mommy/blob/aa7801b3a69d789d52a72436c94cfdd8c6fe6e12/build.rs#L40C15-L56

break up the string formatting into several iterative steps, then disable the ones you don't want in the binary (forget if build.rs makes reading features messy).

mommy WILL threaten to punish you if your code won't compile

An option to integrate with buttplug.io it can make coding extra fun and encourage you to fix all your issues~

Lots of people aren't terribly familiar with how to use env-vars, so having some more explicit guides on how to put stuff in rcfiles persistently, example configs, what to do on windows, etc. would be great.

Currently crates.io has version 0.2.1 and the main branch has version 0.2.0. Probably the modular-mommy branch containing the 0.2.1 release should be merged into main?

i promised ages ago to document this and then i never did lmao

here is a dump of my ~/.profile, which makes e.g. cargo build act as if you'd run cargo mommy build

# mommy loves you~
cargo() {
    case "$1" in
    +*) toolchain=$1
        shift
        command cargo "$toolchain" mommy "$@"
        ;;
    *) command cargo mommy "$@";;
    esac
}

I intentionally avoided abdl stuff in the base moods because that is Contentious Content (and not my scene) but i know a lot of people are clamouring for it so i would certainly accept a PR to add little/little-thirsty/... moods (probably you'd want some extra granularity here, idk, do what you think your kinda people would like)

• docs on the responses.json format
• how to add new moods
• how to add new variables
• how True Roles let you have multiple cargo-mommy profiles

our master is mistress mommy

relevant how-to comment: https://www.reddit.com/r/ProgrammerHumor/comments/19eekgp/comment/kjcmu3h/?utm_source=share&utm_medium=web2x&context=3

y'all keep submitting optimizations but what the world really needs is a bigger pool of responses from mommy:

Hi! It would be fun if cargo-mommy supported runtime loading responses.json with custom responses.

"cargo mommy i mean hello/there" will actually "work" in that we'll do some thing to the filesystem but uhhhh it shouldn't.

Might also be some other degenerate inputs we should reject.

Users should be allowed to write

cargo mommy i mean mommy test

Many people have asked, it might be reasonable to have the cargo-mommy package include two binaries: cargo-mommy (the current one) and mommy (a new one). The mommy binary would behave more like time or whatever, in that it would execute all the arguments that follow, without any notion of "re-invoking cargo". cargo mommy check would be basically equivalent to mommy cargo check, i think.

If we want to do this, the bulk of main.rs should be hoisted into a new lib.rs, as both binaries would share most logic.

They would basically differ in the cli logic in main.rs:

I was thinking about #28 and checked out how cargo mommy fuzz works at the moment. A fuzzing failure works, since it exits with nonzero status, but fuzzers typically run indefinitely (or until you get bored, rather. Unless you set a timeout), so you ^C them, which leads mommy to have no output.

Not outputting anything for a normal command seems fine (unless you wanted to make a quip about how impatient the user is, which would be a third response type I think), but at least for a fuzzer which generally always will be exit with ^C, not doing anything doesn't seem great. Treating it as a success would be fine?

Making this issue mainly to get feedback on how we should act here, I have no firm opinions.

I have extremely severe Tourette's Syndrome, and almost all of my triggers are extremely common, and cause me great physical pain through motor tics (taking the form of painful twitching). Unfortunately, some of my triggers are in the current database of responses for certain moods, so I can't exactly use the full extent of cargo-mommy's features, without editing responses.json. Thankfully, if cargo-mommy supported regexes (with hex escapes so that I don't have to type my triggers, since that would also trigger me) for filtering out certain responses via an environment variable, all I'd have to do is set an environment variable in my .bashrc or whatever, and cargo-mommy would be safe for me to use. Sadly, I don't have much experience with the Rust ecosystem, so I have no idea what crates would be best for this, or how to implement this effectively.

This line in the thirsty, positive responses doesn't work if one changes the default pronoun:

                "give {pronoun} a kiss~",

With the default pronoun of "her", it reads "give her a kiss", which works. But if one changes the pronoun to "their", it reads "give their a kiss". If one changes the pronoun to "his", it reads "give his a kiss". "their" and "his" are the two alternative pronouns mentioned in the README, so they should be supported.

The problem arises from the fact that "her" is used elsewhere as a dependent genitive pronoun, corresponding to "his" and "their", but is used here as an accusative pronoun, corresponding to "him" and "them".

To fix this, I think it would be easiest to say that "her" should always be used in parallel with "their" and "his", in the dependent genitive case, and to change this response to

                "give {role} a kiss~",

e.g. "give mommy a kiss~".

I think it's better to use honey or darling.
I will fork the project, for Chinese adaptation.

10/10. One of the programs ever written and I hate it with every fibre of my being. And am currently installing it on every computer I own. 10/10.

Now that the mood system exists, one could imagine having furry/furry-thirsty/... moods.

Mostly I just think it would be really funny to auto-enable these if you run cargo mommy fuzz

• docs on the responses.json format
• how to add new moods
• how to add new variables
• how True Roles let you have multiple cargo-mommy profiles

The behaviour of cargo-mommy is legitimately getting so complex that an actual CI/test-suite would probably be a good idea. I am always inclined towards using something like cargo-insta for snapshot testing rendered outputs, although I'm not sure the codebase is well-factored for that kind of thing.

...

~

I've setup an alias cargo="cargo mommy", sadly when doing something like cargo +nightly check, cargo tells me

error: no such command: `+nightly`

	Cargo does not handle `+toolchain` directives.
	Did you mean to invoke `cargo` through `rustup` instead?

and mommy tells me I can do better. I'd very much like to, but I don't think I can

The more I've been thinking, the more I think that this doesn't actually need to a cargo extension. It doesn't get much from it at all. Although this probably is just a side product of wanting to learn how cargo extensions work, I think it's done it's job for that use case. I can see one problem stemming from converting this to a standalone binary: people may try to use it in contexts outside of the rust compiler, and that means any 'compiling'-specific responses may not make sense, which I think would be quite sad and restrictive.

https://github.com/sudofox/shell-mommy

hope that's alright, i reused your texts