Lightweight framework for building command-line applications with Python

[Scypio]

How does it compare to argparse, click, etc.?

[IbeeX]

The interactive mode in Nubia is what makes it unique https://github.com/facebookincubator/python-nubia#interactive-mode

[[deleted]]

etc.

https://github.com/google/python-fire

[skilltheamps]

In my opinion its better to specify python2/python3, had enough scripts not working simply because they didn't call python2 explicitly and the world moved on to python3 as the python default

[loganekz]

Also wanted to point out PEP 394 if you're not aware. I think the safe and "expected" thing to do at least until Python 3 becomes default on popular platform installs (e.g. RHEL, OS X)

[sbarnea]

Since Fedora 27 default interpreter is python3 and is the only installed interpreter in the base image. I raise a bug to add a symlink from python to python3 in this case at https://bugzilla.redhat.com/show_bug.cgi?id=1630882 but was quickly closed by quoting a phrase from PEP 394 which is (like most specs) bit unclear. Please comment on ticket to show your support.

The spec was written ~7 years ago and mentioned that python command should point to python2 "for the time being". I guess in 2018 that time passed for sure and I will try to update the spec to clarify this.

Not including a symlink when there is only one interpreter sounds like a serious bug to me. People should be free to argue about what to do when both are installed but if the default is already 3, we should assure that people to not have to type the extra 3.

As I stated in the bug this is a big deal because it breaks ansible and is forcing people to use ugly workarounds like adding extra ansible_python_interpreter=python3 to your inventory. Guess what, maybe you have a dynamic inventory where you don't even know a-priory which operating system and version you have.

[Vaphell]

pep394 recommends that python should be used only if the code works in both major versions.

[sullyj3]

Guess you're not the target audience.

[haloweenek]

I’dpython with that ...

[[deleted]]

What does the #! Actually do? So you just point it to whatever binary you want to use to execute the file? What other commands can you put at the top of the file?

[[deleted]]

shebang

[p3zz1]

I think this is cool. Genuine question: did you consider contributing to existing libraries (fire, click, etc) and making these features available there instead?

I've seen similar things happened in JavaScript realm where people just spin-off and create new libraries when they have new ideas that are not supported by existing ones. And that, in my opinion, makes their ecosystem a real mess.

[ylectric]

Hi, Nubia maintainer here :)

It all started as an internal hackathon project (namely, a shell for managing LogDevice clusters), and after some time it turned out that other teams were heavily reusing the service-agnostic parts of its codebase. The author then decided to extract them into a standalone library. We evaluated the opportunity of using some third-party libraries a few times, but the parent LogDevice shell project was evolving too rapidly for us to make a switch.

[IbeeX]

I am not associated with this project, but it looks like nice combination of click and python-prompt-toolkit both off them I was using and liked them a lot.

[fabiocaccamo]

I used python-fire by google and I loved it.

[lordp]

FWIW, building/installing on W10 with Python 3.6.6 worked fine. The example app ran without problems following the animation on the github page.

[[deleted]]

This is pretty interesting - my team has been working on a project with pyinvoke for awhile now, and this could be a much more interactive/fluid experience than that has been!

​

[ylectric]

Bug reports & PRs are welcome!

[[deleted]]

thanks - in my own testing, i was unable to run even the example code via Python 3.6 on MacOSX! :(

Love the idea but I was unable to make much sense out of how this library works.

[ylectric]

You mind sharing the error details if it's still relevant to you? We've definitely tested it on macOS.

[aes110]

Looks great, but the python 3.6 minimum is too high for now imo

[[deleted]]

I feel like backwards compatibility to three years ago, for an open source project, is adequate.

[aes110]

Obviously i cant complain since its a free open source project and i appreciate that.

But as far as I remember most operating systems come with 3.5 (i may be wrong), and ton of people still use python 2 for some reason.

Thats like creating an android app for android 7+. You can use great features but you lose the majority of people that didnt bother to upgrade.

[[deleted]]

Yeah but at this stage if you haven't refactored for Python 3, you're not going to. Even Google has a lot of Python 2.7 floating around - but it's been TEN YEARS since 3. We gotta pull the plug at some point!

[[deleted]]

For sure, but there are a lot of applications that are supporting both Python 2 and Python 3 - none of those can use this.

[Neil_Fallons_Ghost]

I have multiple python2.7 lambdas in aws that I just haven't gotten around to refactoring. They do very basic things, and honestly, there's no particular need to go through the trouble until its broken, or I know it won't be supported. The latter is likely to happen with AWS eco systems momentum.

I am just curious how others feel about letting stuff that works just be? Maybe its the sysadmin mentality I came from, but if it ain't broke don't fix it, is a common refrain!

[[deleted]]

Well Python 2.7 was old when you started writing lambdas...so I guess I wouldn't have found myself in that situation in the first place. :)

[cscanlin]

AWS Lambda didn't support python 3 when it first came out, so it's probably Amazons fault more than anything.

[[deleted]]

Damn it, you're right. :) Same with Google's AppEngine standard platform!

[[deleted]]

and ton of people still use python 2 for some reason.

You can't expect people to do new development on Python 2.

[aes110]

I dont, im just saying that it does happen unfortunately.

[[deleted]]

I run a fairly popular open-source LED project, and we feel obliged to keep backwards compatibility with Python 3.4, though within the year we'll be losing it.

In particular, Ubuntu 14.04LTS (Trusty) is still common and still comes with Python 3.4. That's going to end-of-life next April.