kybouw / budg

My personal budgeting assistant. My tool for budgeting paychecks and deciding how to spend my hard-earned cash.

This is a Next.js project bootstrapped with create-next-app.

Getting Started

First, run the development server:

npm run dev
# or
yarn dev
# or
pnpm dev
# or
bun dev

Open http://localhost:3000 with your browser to see the result.

You can start editing the page by modifying app/page.tsx. The page auto-updates as you edit the file.

This project uses next/font to automatically optimize and load Inter, a custom Google Font.

Learn More

To learn more about Next.js, take a look at the following resources:

• Next.js Documentation - learn about Next.js features and API.
• Learn Next.js - an interactive Next.js tutorial.

You can check out the Next.js GitHub repository - your feedback and contributions are welcome!

Deploy on Vercel

The easiest way to deploy your Next.js app is to use the Vercel Platform from the creators of Next.js.

Check out our Next.js deployment documentation for more details.

budg's Issues

Ways to verify floats

I found a few ways to verify floats on this Stack Overflow post. My current try...except solution works fine and is valid, but I do have concerns regarding what float() considers to be an error. Namely, scientific notation, infinity, and booleans should probably not be considered valid dollar amounts for a budgeting program.

add option to switch plans

Sometimes I use this to budget my investment portfolio. I do some rename funny business to do that. It would be cool to have a built-in option to switch to another plan just for a single run.

add documentation to code

should add types to arguments and return values on each function, and a docstring

Premature packaging

On the branch console, I began working on the console and budget modules within the budg package, as I believed the program would be much more functional that way.

After toiling with how to implement this change, I figured that I was trying to force an object-oriented philosophy into a project that was not quite ready for that level of functionality. There was just too much that I needed to figure out before I can get to that point.

As such, I am leaving the console branch and continuing on the main budg.py script until the program has matured further. Hopefully, the program will get to a point where abstracting out the components of the program will be more organic.

Changing Licenses

I would like to switch from the MIT License to the GPLv3 license.

Parse should happen outside of budget

parseBudget() should not be called in budget(). This would mean that budget.ini is located and parsed each time a dollar amount is budgeted. This does not make sense, as in later versions, the user should be able to launch the program and edit their budget file. This means that the parse should happen in somewhere in main() (or during initialization of interactive mode).

Move budg plans to userhome/Documents

I feel like this plan file should be more out in the open and not hidden in the .config folder. Plus, I mean, your budget plan is a financial document, right?

In addition, I want to create a config file that holds the path to the plan files so that the user could change where plans are kept on their device.
This also means that the installer will need an update.

Get rid of the scripts folder by making budg.py the executable

You can make .py files executable, and as long as they have the proper shebang at the top of the file, they can be interpreted as commands.

I will only adopt this behavior if it allows me to drop the .py extension. Thus, keeping the budg command.

Redundant default config

A default config file is created in two ways:

1. The install script copies the defaultbudget.ini file into the config directory
2. The .py script itself will create the same default budget file if one does not exist

This should be handled by one or the other, but certainly not both.

Create a budget plan object

Create a python object to represent a plan

You can create subdirectories with mkdir

Instead of checking the directories' existences in steps, just check to see if budg/ exists and then use mkdir -p if it does not.

README needs more info

The README currently just holds a brief description of the program and a License Notice.

It needs to include sections for installing the program and using the program.

I think it should also include a guide for the config file.

Interactive Mode

An interactive mode will be created, and it will be awesome.

More to come...

Rounding values needs improvement

When a dollar amount is multiplied by the budget percentage, it is then divided by 100. This introduces an opportunity for a rounding error, where the budget produced may have a total that is not equal to amount inputted. It is only a matter of pennies, but the program should have some way to consistently deal with this.

Output formatting

The output formatting is a little rough. It could be a bit prettier and more consistent.

There are ways to make text justified to the left or right, as well as ways to make tables with fixed widths. Look into this f-string guide.

Passing string in as argument breaks the script

Passing in a non-decimal value breaks the program because it will try to convert it to a float without checking it. An error is thrown instead of handling it gracefully.

Create a budget plan service that reads/saves to file

We need a separate file service that will read/write plans to the filesystem.

The term "budget" is used too much

I think that the term "budget" is used too ubiquitously.
At the moment, a "budget" refers to the ini file that contains the rules for a budget, as well as the function for calculating the amount of money that goes into each line item.
In the future, there will be multiple files that all amount to a single budget. The name of the program is budg. It is a budgeting program. A budget should refer to a bigger and more abstract idea or concept.

I am considering new names for the files that contains the categories and line items of the budget. Post new ideas here.

change plan file format to TOML

The project currently uses the INI file format to store budget plans. This file format is not standardized and does not include many of the bells and whistles that other file formats provide. Switching to TOML will allow the plan file to accomplish more as the project gets extended.

Reasons to switch to TOML

• INI is not standardized (the only documentation out there is a wikipedia page)
• TOML is well-defined and well-supported
• built in support for data types
• comments
• easy to read and edit
• easy for tools to edit

References

• https://github.com/toml-lang/toml#comparison-with-other-formats
• https://peps.python.org/pep-0518/#other-file-formats
• toml-lang/toml#845 (comment)