kurl VS jesth

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

- 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

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

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