Comments (10)
To avoid this in the future, either prefix the tags with a v or use a different branch name, e.g. 0_8_1 or release_0.8.1.
I thought this meant adding a v prefix would be a good idea? And indeed, I have used this system in other projects in collaboration with others where we are more careful with versions etc...
Indeed, this was one of the options I suggested. Both will work. It's not a question of right or wrong. In these circumstances, I, personally, would have gone for a different branch name. Branches are bit more flexible with regards to renames.
But if you stick with the v
prefix going forward and, maybe, switch to semantic versioning internally and when tagging, all will be fine. I already adjusted our tooling and test built the new release. Now waiting for bioframe
to be reviewed...
from adjusttext.
There's more trouble.
Since 0.8.1
is a tag as well as a branch, the following URL is ambiguous: https://github.com/Phlya/adjustText/archive/0.8.1/adjustText-0.8.1.tar.gz
Downloading that tarball, as our tooling does, results in a tarball that is not a tarball, but a text file with the following line in it:
the given path has multiple possibilities: #<Git::Ref:0x00007fa47b7e35c0>, #<Git::Ref:0x00007fa47b7e28a0>
To avoid this in the future, either prefix the tags with a v
or use a different branch name, e.g. 0_8_1
or release_0.8.1
.
from adjusttext.
There's more trouble.
Since
0.8.1
is a tag as well as a branch, the following URL is ambiguous: https://github.com/Phlya/adjustText/archive/0.8.1/adjustText-0.8.1.tar.gzDownloading that tarball, as our tooling does, results in a tarball that is not a tarball, but a text file with the following line in it:
the given path has multiple possibilities: #<Git::Ref:0x00007fa47b7e35c0>, #<Git::Ref:0x00007fa47b7e28a0>
To avoid this in the future, either prefix the tags with a
v
or use a different branch name, e.g.0_8_1
orrelease_0.8.1
.
Note that it’s possible to work around this by writing the URL as https://github.com/Phlya/adjustText/archive/refs/tags/0.8.1/adjustText-0.8.1.tar.gz instead, although this is not ideal.
from adjusttext.
Note that it’s possible to work around this by writing the URL as https://github.com/Phlya/adjustText/archive/refs/tags/0.8.1/adjustText-0.8.1.tar.gz instead, although this is not ideal.
Indeed. Another option for Fedora packagers fond of forge macros is to use the commit hash for the tag. Something like:
Version: 0.8.1
Release: %autorelease -n
Summary: Automatic label placement for matplotlib
BuildArch: noarch
# Use commit because tag is ambiguous with branch using the same name
%global commit e3904a168581d1a9f67e7399ac01f6ad6f578c43
%forgemeta
License: MIT
URL: %forgeurl
Source0: %forgesource
from adjusttext.
Thank you all for the comments. I just released a new version (1.0!), did I do it correctly?
from adjusttext.
I just released a new version (1.0!), did I do it correctly?
Well, it's a match (kind of). Looking in _version.py
, the version is 1.0. GitHub has it as 1.0.0. Normalized, these are referring to the same version. However, it might be even cleaner if you'd use semantic versioning in _version.py
as well, e.g. define the version as x.y.z.
But why did you switch to munged versions with regards to the tags. The tag for the 1.0(.0) release is v1.0, while all previous tags just used the version without the v
prefix. It's not a big deal and a lot of projects do that. I was just wondering why you started with it now. Same here, you might wanna use semantic versioning for tags as well.
from adjusttext.
the version is 1.0. GitHub has it as 1.0.0.
Good point, I missed that indeed.
To avoid this in the future, either prefix the tags with a v or use a different branch name, e.g. 0_8_1 or release_0.8.1.
I thought this meant adding a v prefix would be a good idea? And indeed, I have used this system in other projects in collaboration with others where we are more careful with versions etc...
from adjusttext.
Someone else asked to review whether depending on bioframe is necessary, and I just copied over two necessary functions from there. So you don't need to wait for the bioframe review...
I released some new versions, only the latest one (1.0.3) is packaged correctly :)
from adjusttext.
Someone else asked to review whether depending on bioframe is necessary, and I just copied over two necessary functions from there. So you don't need to wait for the bioframe review...
Oh well, it just got reviewed and is now available in Fedora's rawhide repo. I'll keep it for now. If it turns out to be a burden I can always retire it again later. But thanks for looking into it and making the required changes dropping bioframe as a dependency.
I released some new versions, only the latest one (1.0.3) is packaged correctly :)
As the saying goes: the third time is the charm. ;)
Or maybe not... (see #168)
from adjusttext.
Oh well, that's embarassing! I noticed this import was a problem for building the docs, so I removed it - should have realized it's an issue in general! I'll make a new minor release now... Thank you for letting me know!
from adjusttext.
Related Issues (20)
- Backends to use in a multithreaded environment HOT 4
- Time Limit HOT 2
- Altering Data HOT 3
- Example of integrating seaborn.object()
- Plotly support? HOT 1
- Feature request: Fix output (specify iteration limit instead of time) HOT 2
- Is the `bioframe` dependency necessary? HOT 3
- Just started not working one day with this error HOT 2
- Version 1.0.3 has a non declared dependency on pandas HOT 1
- force_points key word removed? HOT 2
- Labels misplaced in subplots HOT 1
- Issue with "matplotlib.axes.Axes.annotate" using the arguments "xytext" and "textcoords" HOT 5
- Poor Result when avoiding a polygonal curve HOT 6
- adjustText 1.1 doesn't work properly anymore HOT 6
- Arrows disappear when using cartopy transformation HOT 11
- query_pairs unexpected argument HOT 3
- Numpy 2.0 related issue - use of 'np.Inf`' HOT 3
- update to work with numpy 2.0 HOT 1
- Prevent text overlapping scaled scatter points HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from adjusttext.