Publish to pypi
dkuschmierz opened this issue · comments
Hi @jedrzejboczar
I forked this awesome script and refactored it, added json support and created a project out of it. Now, after some more beautifying and adding some UnitTests, I want to publish it to pypi. Is it ok for you if I publish it from my repository or do you want me to create a PR for your repo and you publish it to pypi?
Hi @dkuschmierz,
Thanks for your work. I initially written this as a single-file project in order to make it really simple to run, but it probably makes sense to package it to pypi.
I don't think that I have a lot of time for maintaining this script, so if you intend on extending the functionality and overall maintaining, then feel free to publish this from your repo. Also, if this is something that blocks you (your work, research, etc.) then publish from your repo as this will probably be faster and I don't have a problem with it.
On the other hand it might be confusing if the project was split (having this repo and the fork with a refactor and published version), so it might be overall beneficial to keep it on this repo. But if you decide on contributing here, than I'd say it would be better to take time and split the changes into multiple PRs like: JSON support, refactor, python package setup, etc. I'd probably also propose some minor changes, as well as I'd vote for keeping the name as elf-size-analyze and using snake_case for file/module names, as camelCase files/modules look somewhat weird to me, but I guess this is my personal preference and I might be annoying :)
If you decide to publish from your repo, than I'd like to add JSON support in my repo too in the near future. I hope it wouldn't be an issue to base on your changes?
Also, I tested your JSON support and I noticed an issue: when the file name doesn't have .elf extension, then you overwrite the initial file. When creating a new file name, it would be better to replace ".elf" with "" and then adding the rest. But I'd actually suggest always printing to standard output, the same as with printing. Users would be able to pipe the output to a file if needed (elf-size-analyze -j ... > output.json), but of course this imposes a question what to do when printing e.g. both ROM and RAM (two separate JSONs? wrap everything in another json with "rom"/"ram" keys, etc.).
And a minor typo: when generating JSON you use "childrens", which should be "children".
What do you think about it? If you have any questions feel free to ask.
Hej @jedrzejboczar,thanks for your feedback and especially for your findings! I will definitely fix them.
I renamed the modules as dashes are not allowed in module names as far as I know and I am used to camel-case. But I'm absolutely open to change this to snake_case.
Regarding publishing to pypi it depends on how much time you have to maintain. I will use this script intensively and need to quickly fix upcoming bugs and release new versions. So if you say you can merge quickly PRs (in a few days) I will create a PR and we can publish it from your Repo, otherwise I will do it from my repo. For sure you can pick the json-support.
Another option would be making me a contributor of this repo so we can both work on this repo.
Think about it and let me know!
I think that merging bug fixes/etc quickly wouldn't be a problem, but I like the idea of adding you as contributor, in fact I was already considering this. So if this is ok for you, then I'd suggest to first add your changes in at least 3 separate PRs:
- JSON support, probably with format description in readme or some test-example
- code refactor - splitting the single-file into multi-file python project, no changes in functionality
- python package - setup.py, pyproject.toml, etc.
I know it will be more work, but this way we can have clean git history and it should be easier to review the changes. JSON support could be the last one instead of first one if it will be easier that way.
@jedrzejboczar I now created a PR for the changes. I decided to split it up in two commits. One which adds the JSON support and the other which does the refactoring and creates a package, as this comes more or less hand in hand.
If it is fine for you I would be happy if you can add me as a contributor!
Hej @jedrzejboczar, I cannot set up the GitHub action to automatically publish to pypi, as I cannot access the settings/secrets menu for this repo. Can you please have a look if you can grant me the permissions?
I also saw that you created the tag v0.1.0. I think we should go with semantic versioning and get rid of the leading v, is this fine for you?
@dkuschmierz I don't see any option to manage collaborator permissions. I see the following
Secrets are environment variables that are encrypted. Anyone with collaborator access to this repository can use these secrets for Actions.
so maybe I can just add the secret and you should be able to use it. Could you point me on what exactly is needed?
Regarding tags, no problem to use 0.1.0, I just added "v" out of habit.
@jedrzejboczar I just created 0.2.0 and published the project now to pypi. This was necessary to initially create the project on pypi. You should now register an account on pypi.org and tell me your username, then I can add you as the owner of the project. After that, you should go to the project settings and create an API token and add it to the secrets...
This would be the manual how to create/add the token...
@dkuschmierz Ok, I created the account: https://pypi.org/user/jedrzejboczar/
Added you as an owner!
Ok, I added PYPI_API_TOKEN secret, you should be able to use it. Should I also add the TEST_PYPI_API_TOKEN?
Don't think that this is necessary, as we can also install directly via pip and do not need not tagged versions via the testing index. Will try to set it up tomorrow!
Automatic package upload now in place!