Re: Time for a request-for-comments process?
Hello, Em quarta-feira, 27 de outubro de 2021, às 19:28:14 -03, Katherine Cox- Buday escreveu: > Ludovic Courtès writes: > > I think a major goal of the process would be to formalize a minimum > > and a maximum duration under which an RFC is under evaluation, and a > > mechanism to determine whether it’s accepted or withdrawn. > > I think it's a good idea. Me too. > The only contribution I can give is that I > would not have known =guix shell= was coming had I not been watching the > patches list. So in addition to formalizing what you've mentioned, I > suggest we also formalize a location to watch (guix-devel seems > logical?). I agree that guix-devel is a good place to announce new RFCs, probably using an eye-catching subject prefix so that we can more easily see and filter them. For RFCs where users are also stakeholders, we should also announce in places where users are likely to see them, such as the info-guix and help- guix mailing lists, and possibly even the Guix blog (how far out do we want to spread the word?). “guix shell” would have been an RFC with users as stakeholders, but I can imagine others where that isn’t the case, such as some significant but internal code reorganization. -- Thanks, Thiago
Re: Time for a request-for-comments process?
October 27, 2021 6:51 PM, "Katherine Cox-Buday" wrote: > Ludovic Courtès writes: > >> I think a major goal of the process would be to formalize a minimum >> and a maximum duration under which an RFC is under evaluation, and a >> mechanism to determine whether it’s accepted or withdrawn. > > I think it's a good idea. The only contribution I can give is that I would > not have known =guix > shell= was coming had I not been watching the patches list. So in addition to > formalizing what > you've mentioned, I suggest we also formalize a location to watch (guix-devel > seems logical?). That's why I didn't see guix shell coming. I don't follow guix patches... > -- > Katherine
Re: Time for a request-for-comments process?
October 27, 2021 5:23 PM, "Ludovic Courtès" wrote: > Hello Guix! > > The recent ‘guix shell’ addition is almost anecdotal technically yet > important for the project because users interact with Guix primarily > through the CLI. Adding a new command is a commitment (our users must > trust it won’t change overnight), and getting the details wrong could > make us fail to honor that commitment. > > For ‘guix shell’ I left time for comments and repeatedly asked people to > comment; yet pushing it was a bit stressful: Did I make a mistake? Did > everyone with a stake in this really have a chance to comment? I absolutely love the new guix shell! "-ad-hoc" was a bit confusing to understand. I know more about guix shell in 5 minutes than I did with a few years of guix environment! > That makes me think it’s perhaps time for a formalized > request-for-comments (RFC) kind of process for such “major changes”. We > could draw inspiration from one of the many existing processes: Python’s > PEPs, Scheme’s SRFIs, Nix’s RFCs, Rust’s MCPs, etc. I think a major > goal of the process would be to formalize a minimum and a maximum > duration under which an RFC is under evaluation, and a mechanism to > determine whether it’s accepted or withdrawn. I'm all for a RFC! Somehow I missed any communication about this new guix shell, and I normally follow the mailing lists like a 11th grade stalker (not that I have any experience with stalking...I can't really discuss it until the lawsuit is over...). But then again my comments are perhaps not as weighty as others? I have only really been the occasional guix documentation writer. > Thoughts? Anyone with experience with such a process? > > Ludo’.
Re: Time for a request-for-comments process?
Ludovic Courtès writes: > I think a major goal of the process would be to formalize a minimum > and a maximum duration under which an RFC is under evaluation, and a > mechanism to determine whether it’s accepted or withdrawn. I think it's a good idea. The only contribution I can give is that I would not have known =guix shell= was coming had I not been watching the patches list. So in addition to formalizing what you've mentioned, I suggest we also formalize a location to watch (guix-devel seems logical?). -- Katherine
Time for a request-for-comments process?
Hello Guix! The recent ‘guix shell’ addition is almost anecdotal technically yet important for the project because users interact with Guix primarily through the CLI. Adding a new command is a commitment (our users must trust it won’t change overnight), and getting the details wrong could make us fail to honor that commitment. For ‘guix shell’ I left time for comments and repeatedly asked people to comment; yet pushing it was a bit stressful: Did I make a mistake? Did everyone with a stake in this really have a chance to comment? That makes me think it’s perhaps time for a formalized request-for-comments (RFC) kind of process for such “major changes”. We could draw inspiration from one of the many existing processes: Python’s PEPs, Scheme’s SRFIs, Nix’s RFCs, Rust’s MCPs, etc. I think a major goal of the process would be to formalize a minimum and a maximum duration under which an RFC is under evaluation, and a mechanism to determine whether it’s accepted or withdrawn. Thoughts? Anyone with experience with such a process? Ludo’.
Issues with v910 of mypy
Hi all, Was wondering if anyone had come across the issue with mypy using modular stubs in v910. As far as I can see installing for example python-types-requests and python-mypy in Guix leads to mypy ignoring the supplemented request stubs provided by the types-requests package. I've raised this on mypy, but it not really a mypy bug as there solution does work with pip (although other package managers like PDM have reported similar issues): https://github.com/python/mypy/issues/11395 Was wondering if anyone has a) experienced the same issue? b) had a workaround? I could consider downgrading mypy to the last non-modular stub version if this issue is widely expreienced and there is no immediate workaround from guix or mypy message boards? As it standards the version in guix is pretty unusable to anyone developing outside of python core library sets and using mypy - we'd be better on a slightly older version that works for now, I think? Thanks, Phil.
