Backstage Alternatives

backstage reviews and mentions

• Show HN: Paradict – Streamable multi-format serialization with schema
  4 projects | news.ycombinator.com | 18 Dec 2023

  Although most languages allow Unicode characters in identifiers, for better code portability and readability, we agree to stick to ASCII characters. Since we're already sticking to ASCII characters in our source code, I think we'll be less 'astonished' to encounter similar rules for our configuration keys (especially when a key-value pair in the Paradict configuration file looks like an instruction for variable assignment).

  > I don't get the a-z benefit in the argument case - the user must type "arg1" precisely for the argument names to match...

  Absolutely ! The user must type "arg1" precisely because this is part of the implicit agreement between the user and the system. If the user forgets to type "arg1", the default value will be taken into account. If the user adds an additional unexpected key (a typo for example), it will be stored in "kwargs" and then ignored or used to warn the user.

  I plan to build two flagship projects to leverage Paradict binary and textual formats: a lightweight database and an automation tool. The automation tool will consume a configuration file a bit like another project of mine does (https://github.com/pyrustic/backstage).

  And this is where I join you. I think we'll both agree that since a shell command is already likely to have quotes around some of its arguments, it's very annoying to put extra quotes around it. So I'm thinking of introducing a Command data type:

    # typing 'start' in the command line will run

• Show HN: Jesth – Next-level human-readable data serialization format
  6 projects | news.ycombinator.com | 18 May 2023

  Jesth is like a broken INI file parser that can only split a document into sections (each section consists of a header and a body which is just a list of strings).

  Now, on top of that, I can write a hack to convert an arbitrary section to a dictionary data structure (provided the body of that section is written with a specific syntax designed for my hack).

  I made this hack and included it in the Jesth library, so people can use it, much like the Python standard library is just there to help people not waste time rewriting the same algorithms for common tasks.

  Jesth would be like JSON which is only about data. CUE, Dhall and Jsonnet jump on top of JSON to add some cool stuff.

  I used Jesth for example to design a docstring markup language [1], as well as a scripting language [2].

  I will soon publish a simple data validation mechanism for Jesth dict-sections (sections intended to be converted into a dictionary data structure). It might inspire people to create a more complex data validation or data constraint language on top of Jesth. This could be more readable than what is done elsewhere.

  [1] https://github.com/pyrustic/jesth/tree/master/docs/modules

  [2] https://github.com/pyrustic/backstage

• Show HN: Backstage – Three-speed scripting language and task automation tool
  1 project | news.ycombinator.com | 15 Sep 2022
• Scientists Discover 380M-Year-Old Heart, Preserved
  2 projects | news.ycombinator.com | 15 Sep 2022

  Hi HN !

  I'm Alex, a tech enthusiast who likes to build stuff from scratch.

  The more time we spend doing something, the more comfortable we feel and the less dependent we are on an external learning resource. Since I spend a lot of time in a text editor, I can spend days writing Python code without checking an online resource. On the other hand, since I spend so little time in the command-line shell, I often found myself looking online for commands to build and publish Python packages.

  Considering the text editor and files as the software development stage [1], the backstage [2] would be the tasks performed in the background to manage the project. These tasks would relate to the different stages of the project lifecycle (build, test, publish, et cetera).

  I thought it would be both cool and useful to have a tool that would serve as the backstage entry point for any of my projects. This tool would be called 'Backstage' [3] and would allow me to quickly discover the available tasks (including their descriptions) for a given project. Tasks would be defined in a file named 'backstage.tasks' (preferably located at the root of the target project) and would consist of collections of commands to be executed sequentially. To execute a task, I would just have to type in the command line its name possibly followed by arguments. For example: 'backstage build' or 'backstage release 1.0'.

  INI File [4] or TOML would be the perfect file format candidate for the 'backstage.tasks' file. But unfortunately they are designed to handle sections with key-value pairs when I need a simple way to define sequences of commands aligned under their respective task name. So I built Jesth (Just Extract Sections Then Hack) [5], a new file format that looks like INI file but lets me decide how to interpret the body of a given section.

  After a few days of programming, I successfully built the first iteration of Backstage and placed a 'backstage.tasks' file in my projects directory. From that day on, releasing a new version of a project was stress-free.

  This first iteration served its purpose as I expected until one day I forgot to enable internet connection while using Backstage to publish a new version of a project. Project documentation was generated successfully, version management, build and 'Git Commit' were done automatically, but 'Git Push' failed and the task was aborted. This specific task was supposed to run without interruption because each time it is executed, unique and timestamped events occur. Enabling internet and re-running this task would update the target project version and create a new superfluous version.

  From that day I understood that I had to improve the syntax of the 'backstage.tasks' file to avoid this kind of annoying situations in the future. The most obvious solution was to introduce variables and control flow. I took the time to anticipate what I will need in the future. Then I decided to add stuff like data types, namespaces, multithreading, test support, builtin commands, et cetera. Eventually, the syntax of the 'backstage.tasks' file evolved into an eponymous (Backstage) three-speed scripting language.

  The three-speed scripting language concept is inspired from the three forward gear ratios of early automobiles transmission system [6].

  In first gear, a `backstage.tasks` file is intended to store a list of tasks related to a specific project, each task exposing a list of commands or subtasks to be executed. Here, a command represents a process or pipeline of processes to be spawned. Environment variables can be used in commands via variable interpolation [7]. No other logic is involved.

  In second gear, the `backstage.tasks` file not only stores the tasks like in first gear, but here logic intervenes, variables are defined, control flow is used, built-in commands are called, et cetera. Basically, in second gear, Backstage unleashes its power and allows the programmer to anticipate problems, make sophisticated combinations of subtasks, in short to write a real script to automate things.

  In third gear, in addition with whatever can be done with previous gears, the programmer can directly from the `backstage.tasks` file, call Python functions with arguments and get the return ! Thanks to this third gear, any too complex or overly verbose calculation can be written in Python and called from Backstage. This functionality alone proves that Backstage is all about making the programmer's life better, not pretending to replace existing mature solutions that actually work.

  These three speeds make Backstage versatile enough to act either as a simple task runner or as a scripting language with a built-in bridge to the powerful Python ecosystem. Not only are tasks defined in 'backstage.tasks', but their documentation and tests can also be embedded there. The command line interface allows the user to discover available tasks, read their documentation, use a glob-like [8] syntax to search for a task by its name or by a keyword that is part of the documentation of the task.

  I use Backstage a lot and want it to stay cross-platform and relevant long term. So, as said before, Backstage has data types, namespaces, multithreading, test support, built-in commands but also regular expression support, timestamp and date/time conversions, support for here document [9] directly in 'backstage.tasks' file, automatic normalization of path strings, intuitive variable persistence mechanism, et cetera.

  Backstage allows the programmer to spawn and pipe processes, capture their output, push data into a process's input, redirect STDOUT and STDERR. File and directory manipulation is intuitive, so one can create, move or copy files or directories with built-in commands, browse an arbitrary directory and access properties such as creation time or size, consume the contents of a large file line by line or in bulk.

  There is more to say, it's a work in progress and I'm excited to share this project with you. Backstage is available on PyPI and you can start playing [10] with it from now. You are welcome to share what you think about this project.

  [1] https://en.wikipedia.org/wiki/Stage_(theatre)

  [2] https://en.wikipedia.org/wiki/Parts_of_a_theatre

  [3] https://github.com/pyrustic/backstage

  [4] https://en.wikipedia.org/wiki/INI_file

  [5] https://github.com/pyrustic/jesth

  [6] https://en.wikipedia.org/wiki/Manual_transmission

  [7] https://en.wikipedia.org/wiki/String_interpolation

  [8] https://en.wikipedia.org/wiki/Glob_(programming)

  [9] https://en.wikipedia.org/wiki/Here_document

  [10] https://github.com/pyrustic/backstage#demo

• Show HN: GUI As Stapled Pages (GASP) – A new way to quickly build Python apps
  5 projects | news.ycombinator.com | 16 Nov 2021

  Hi HN !

  I am excited to publish my very first white paper. I've been working on a framework called TkF (originally called Pyrustic Framework) for several months now, to make Python applications. The framework uses Tkinter (the default Python GUI toolkit), comes with new widgets (megawidgets to be precise), a dark theme, a CLI tool to manage Python projects, and other libraries I have developed for styling, multithreading, etc. I did other side projects to test the framework and discover weaknesses which I then correct. I was happy with the project because it just works.

  But I was not really productive with TkF. It takes a long time to create a GUI [1]. So I thought about creating a GUI builder. After several days of thinking, my thoughts drifted away from the Python philosophy: simple is better than complex. I eventually gave up on the idea of the GUI builder because among other reasons, I don't like using a GUI builder, for example it hides a lot of the complexity that comes back like a boomerang afterwards. A big software bazooka does not necessarily convince everyone, for example many people still prefer to use Vim or Emacs instead of an IDE [2].

  So I created the framework Dresscode. I chose this name Dresscode only to be able to make the sentence "Dress up your code with a beautiful GUI !". If TkF is C, Dresscode would be Python. With Dresscode, main views are Pages and widgets are graphical Components. Dresscode is not a GUI builder but it is designed to build a GUI as fast as a GUI builder but with two drawbacks: you will have to type some code (although it is not a lot of code compared to TkF), and the layout mechanism is not very flexible. Still to allow the developer to be productive, I implemented a very simple idea: a navigation bar automatically populated with references to the Pages (example: Home, About, etc) of the application.

  A few days ago, I was editing the READMEs of each of the Pyrustic Open Ecosystem [3] projects to improve them. The README of the TkF project has a nice cover image [4] which is a screenshot of a demo made with TkF. I wanted such a pretty image for the README of Dresscode. But this demo cannot be done as is with Dresscode without cheating. There are two buttons "Cancel" and "Connect" under a form which cannot be reproduced as it with Dresscode because the layout mechanism is not very flexible (flexibility restricted to gain in productivity).

  I wanted to unlock the potential of the layout mechanism without sacrificing developer productivity. To do this, I introduced the notion of "parent" which allows the developer to freely decide where he wants to install a widget (or group of widgets) on a view. Thanks to serendipity [5], I had other interesting ideas. I thought that all of this might form a concept that can be implemented in other programming languages. So I named the concept GASP: GUI As Stapled Pages. Here, the navigation bar represents the staple. I decided to create a new project and to abandon Dresscode. I wrote the reference framework named Gaspium [6] then wrote a white paper to encourage other people to adopt the concept and implement it in other programming languages (even other implementations still in Python but with Qt or wxWidgets or GTK etc).

  Gaspium is a lightweight framework for building GASP applications and it was created with TkF. In short, we define pages to which we add graphical components. With a single line we add a complex graphical component to a page and the layout mechanism is controlled with only 5 keyword arguments ('parent', 'side', 'anchor', 'fill', and 'expand') whose defaults are sufficient in most cases. Then we add these pages to an instance of the App class. The first page added is de facto the home page and it will be open when the application is started. Adding a page makes it automatically referenced in the application's navigation bar. Each graphical component can be identified with a unique identifier in order to be able to read its content or update it. Each page has a unique identifier assigned automatically or manually. You can open an arbitrary page directly from the command line and even pass data to it. Gaspium is suitable for: building internal tools, teaching GUI programming, building GUI wrapper for command line scripts, prototyping, building utilities for yourself or other programmers, lightweight commercial apps, et cetera.

  The concept of GASP not only makes it possible to be more productive in GUI programming, but it changes the relationship that developer and user have with an application. On the developer side, the concept of GASP structures his ideas to think of his project in independent parts (the pages), which represents a big advantage in terms of organization and maintainability of his project. For the application user familiar with monolithic applications, the concept of GASP turns the application into a series of useful programs, each with a graphical interface that can be invoked arbitrarily from the command line.

  I already use Gaspium according to the principle of dogfooding. Gaspium documentation is still precarious for the moment, but that will change soon. The Pyrustic Open Ecosystem of which Gaspium is a part, has been updated (Generation of documentation, git workflow, packaging, versioning, PyPI release ...) with an internal tool that I created in a very short time with Gaspium and Backstage (Backstage [7] is a CLI tool to manage Python projects). I can't wait to read your thoughts [8] on all of this, or show me a similar project etc. If you hate GUI programming or find it too difficult, I would like to know if this GASP concept makes you want to do GUI programming and why. Thank you for your attention !

  [1] https://blog.codinghorror.com/ui-is-hard/

  [2] https://news.ycombinator.com/item?id=25036036 (Why are so many coders still using Vim and Emacs?)

  [3] https://pyrustic.github.io (Pyrustic Open Ecosystem)

  [4] https://raw.githubusercontent.com/pyrustic/misc/master/asset... (Cover image for the README of the TkF project)

  [5] https://news.ycombinator.com/item?id=1826666 (Paul Buchheit: Serendipity finds you)

  [6] https://github.com/pyrustic/gaspium

  [7] https://github.com/pyrustic/backstage

  [8] http://sl4.org/crocker.html (Crocker's Rules)

• Hubstore – Apps distribution and friend-to-friend promotion
  8 projects | dev.to | 3 Sep 2021
• Show HN: Hubstore – Apps distribution and friend-to-friend promotion
  8 projects | news.ycombinator.com | 2 Sep 2021

  - ensures that more an app is recommended by different developers, as well as a chance to be in the promotion list often (until the user decides to install it).

  The choice to put a Promoted button on which the user can click may seem naive. Implementing intrusive pop-ups can be recommended as a more pragmatic method. This choice to trust the altruistic curiosity of users was influenced by an observation (I have 0 statistics to show) I made here on Hackernews: there are always users who click on Newest (https://news.ycombinator.com/shownew) to bring up posts that might deserve attention, though these users are not affiliated with these posts.

  I want Hubstore to make it easy to distribute and promote Python apps (built with Pyrustic Framework or not). This is still a beta version for early-adopters.

  Under the hood:

  - Hubstore is built with Pyrustic Framework [1]

  - data storage is done with Shared [2]

  - autocomplete is done with Suggestion [3]

  - GUI-compatible multithreading is done with Threadom [4]

  - Hubstore consumes Python Wheels

  - Hubstore uses Github's Release Asset feature [5]

  - Apps can be built and released with Backstage [6]

  - the dark theme is based on Cyberpunk-Theme [7]

  - all views implement Viewable [8]

  - Hubstore uses Kurl [9] to fetch resources from api.github.com

  I would like to know what you think [10] of this project.

  [1] https://github.com/pyrustic/pyrustic

  [2] https://github.com/pyrustic/shared

  [3] https://github.com/pyrustic/suggestion

  [4] https://github.com/pyrustic/threadom

  [5] https://github.blog/2013-07-02-release-your-software/

  [6] https://github.com/pyrustic/backstage

  [7] https://github.com/pyrustic/cyberpunk-theme

  [8] https://github.com/pyrustic/viewable

  [9] https://github.com/pyrustic/kurl

  [10] http://sl4.org/crocker.html

• A note from our sponsor - SaaSHub
  www.saashub.com | 25 Apr 2024

  SaaSHub helps you find the best software and product alternatives Learn more →