Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Proposal for shipping 1.0 #6

Open
wants to merge 6 commits into
base: main
Choose a base branch
from
Open

RFC: Proposal for shipping 1.0 #6

wants to merge 6 commits into from

Conversation

sophiajt
Copy link

This adds the proposed plan for the upcoming releases which aligns us with a 1.0 release as part of our on-going work on Nushell.

The 1.0 release will be seen as an important milestone in Nushell's continued development, so we want to shape how it lands to give it a good chance of success and meeting the needs for both existing and future Nushell users.

We'd love to hear your feedback to help us refine and revise this proposal.

@mgattozzi
Copy link

Rendered view for those who need/want it

@mvolkmann
Copy link

I see this in the list: Use another function to mean "send value to pipeline". I’ve wondered whether that could be implicit for any pipeline that begins with an expression instead of a command. For example, $someVar | where ... | sort-by ... | ...

A key thing to consider is whether anything else could be expected by starting a pipeline with an expression rather than echo. If the answer is "no" then I think this change should be considered.

@ehdevries
Copy link

I would love to have case-insensitive completions, particular for case-insensitive systems like Windows.

For instance, if my current working directory has a sub-directory called "Documents" (capital "D"), then both cd Doc TAB and cd doc TAB should complete to cd Documents.

This would ease the pain of moving from PowerShell to Nushell. Even if case-insensitivity were not the default, having the option to enable it via configuration would be fantastic.

@jakobnissen
Copy link

I would love to see better railguards against accidentally and permamently deleting files. See more discussion about this in this Reddit thread (where I'm viralinstruction). This would be a major usability improvement, I think.

@OvermindDL1
Copy link

@ehdevries It's a useful feature even on case-sensitive systems, I have case-insensitive tab-completions enabled in ZSH and it's such a help. This would be a huge quality-of-life option.

@jonstodle
Copy link

@ehdevries @OvermindDL1 I’m not sure if this still works, but I have this working in an older version of nu with the following config

[line_editor]
completion_match_method = "case-insensitive"

@ehdevries
Copy link

ehdevries commented Apr 1, 2021

@jonstodle That did the trick for me! I'm using the latest version, 0.29, so that config is still valid. Thank you for the tip!

With that in place, the only thing left would be to add this to the Nu Book's section on configuration.

Update - issue to document this setting: nushell/nushell.github.io#116

@stormasm stormasm mentioned this pull request Apr 2, 2021
@kubouch
Copy link

kubouch commented Apr 3, 2021

One thing that I feel is missing from the RFC is integration with outside world. To ensure smooth operation with non-nushell tools.

  1. There is a long-standing exec issue when Linux programs running stuff with exec are broken if nu is set as default prompt (reported here.

  2. Integration with other environments could be considered. For example I use conda for managing Python environments and packages but it doesn't work with nushell. There are probably other similar cases. Even though adding a nushell support to external tools would likely require us making PRs to those tools, it would ultimately help the adoption.

In my case, both the exec issue and the missing conda support are the only reasons I still run bash as a default shell.

@ammkrn
Copy link

ammkrn commented Apr 7, 2021

We'd love to hear your feedback to help us refine and revise this proposal.

I think it would be nice if a 1.0 release identified some kernel of critical features and invariants, and included a set of tests to demonstrate that nu is well behaved with respect to those. I ran into the behavior described in #3116 (should be fixed in #3278) which I think is fairly serious and seems to be caused by something which would have been relatively easy to smoke out using that approach. I completely understand that developers on projects like nu face very real time and resource constraints, but I think potential users would be less hesitant to adopt something as important as a new shell if they had some assurance that it won't do things like permanently delete things on accident, or if they at least knew the developers had this kind of safety in mind.

Thanks for the hard work.

@matklad
Copy link

matklad commented Jun 27, 2023

Seeing https://determinate.systems/posts/nuenv (experiment to use nushell instead of bash for building software in nixpkgs), it seems there's a real demand for 1.0 now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants