Consider creating a semver package
See original GitHub issueDefinitions
- Module A module is a file containing Python definitions and statements.
- Package A package is a collection of modules in directories that give a package hierarchy.
Situation
The current semver.py
module contains almost 800 lines of code. As new functionality is added, the files grows bigger and bigger.
Suggested Solution
Should we consider to refactor the semver module into a package?
If yes, this is a feature which we should introduce for the upcoming 3.0.0 release. Could we label that in GitHub as such (or create a milestone)? 😉
Maybe we should also consider to refactor our test cases too and move them to a tests/
directory and create different files? They are currently almost 700 lines of code.
That issue involves the following actions:
- refactor semver module into package
- Probably introduce a
tests/
directory?
semver/
├── __main__.py # basically imports semver.cli.main and runs main()
├── __init__.py # should contain only the usual constants like __version__, __author__ etc.
├── cli.py # implements the command line interface
└── [... probably more files ...]
An example (although a bit outdated now as new commits arrived in master) can be viewed in my fork). It’s not perfect, but a start.
Pros
- Make files smaller and more readable
- No API change to the user
- Easier to add more functionality
- With
__main__.py
, it is possible to usepython -m semver -h
Cons
- More files means also, to search where a function is defined
- Slightly more difficult to test as it may be needed to run
tox
first or create a virtual environment.
What do you think? 😉
Issue Analytics
- State:
- Created 4 years ago
- Reactions:1
- Comments:8 (8 by maintainers)
Top Results From Across the Web
Semantic Versioning 2.0.0 | Semantic Versioning
Consider a library called “Firetruck.” It requires a Semantically Versioned package named “Ladder.” At the time that Firetruck is created, ...
Read more >About semantic versioning - npm Docs
Incrementing semantic versions in published packages · Using semantic versioning to specify update types your package can accept · Resources · More videos...
Read more >Semver: A Primer - NodeSource
Semver is important in Node.js because it's built into the way that npm manages package dependencies. What's more, semver ranges are almost ...
Read more >Semver explained - why is there a caret (^) in my package.json?
Introducing Semantic Versioning Semantic Versioning dictates what kind of changes cause the version number to be incremented. Semver uses three-part version ...
Read more >A Guide to Semantic Versioning - Baeldung
For example, 1.0.0-alpha.1+001. Build meta-data does not factor in precedence, so we can consider two versions that only differ in build number ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
+1 as it will also reduce the possibility of having conflicts.
But maybe we should consider this for a 3.0.0 release
Looking at the current direction the project is taking, I think we will have 2 files:
version_info.py
: contains theVersionInfo
classcli.py
: contains all the functions used for the cli.Seeing that most module level functions are now being deprecated, I think this layout will be clear and it shouldn’t be too hard to search for a functionality.