Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No support for linking usernames #144

Closed
jaraco opened this issue Aug 25, 2024 · 4 comments
Closed

No support for linking usernames #144

jaraco opened this issue Aug 25, 2024 · 4 comments

Comments

@jaraco
Copy link
Owner

jaraco commented Aug 25, 2024

In jaraco/jaraco.collections#16, the author referenced themselves in the news fragment, but that caused the release to fail (late, only after finalizing the release).

They got the impression they could use this syntax because it was contributed downstream to Setuptools but not to other projects.

We should probably add support for that in all skeleton and coherent projects.

Of course, the way it's implemented is not sustainable because the config requires hard-coded values.

jaraco added a commit to jaraco/jaraco.collections that referenced this issue Aug 25, 2024
@Avasam
Copy link
Contributor

Avasam commented Aug 29, 2024

Oh darn, I've been doing the same for other newly typed skeleton-based projects.

I don't suppose any of this could be pulled from git data when building docs? (idk if the project is checked out just copied)

git config --get remote.origin.url
# or
git ls-remote --get-url origin

Actually github_repo_url is hardcoded per-repo, but I don't see where it's used. :user: looks like it should work for any repo.

@jaraco
Copy link
Owner Author

jaraco commented Aug 29, 2024

Oh! Great observation. Yes, that should be trivial to add. I'll do that.

@jaraco
Copy link
Owner Author

jaraco commented Aug 29, 2024

I'm wondering which is best - github.com/{username} or github.com/sponsors/{username}. My instinct would be to simply link to the user, and let a potential sponsor traverse to the sponsors page if appropriate. It feels a little sketchy to drive users to the sponsors URL when all they're doing is clicking on the "user". After musing about it for a moment, I think I prefer the non-sponsors page. Let's go with that for now until someone else is willing to make the case for the sponsors page.

@jaraco jaraco closed this as completed in 2beb8b0 Aug 29, 2024
@Avasam
Copy link
Contributor

Avasam commented Aug 29, 2024

It's also odd if there user hasn't setup sponsors. I'm in favor of linking to the profile page as well.

clrpackages pushed a commit to clearlinux-pkgs/pypi-jaraco.collections that referenced this issue Aug 30, 2024
…0.1 to version 5.1.0

Anderson Bravalheri (1):
      Add `--fix`  flag to ruff pre-commit hook for automatic suggestion of fixes (jaraco/skeleton#140)

Avasam (4):
      Add Protocols, remove @overload, from `.coveragerc` `exclude_also` (jaraco/skeleton#135)
      Loosen restrictions on mypy (jaraco/skeleton#136)
      Pass mypy and link issues
      Fully typed `RangeMap` and avoid complete iterations to find matches (#16)

Bartosz Sławecki (1):
      Move project metadata to `pyproject.toml` (jaraco/skeleton#122)

Dimitri Papadopoulos Orfanos (3):
      "preserve" does not require preview any more (jaraco/skeleton#133)
      Enforce ruff/Perflint rule PERF401 (jaraco/skeleton#132)
      Update to the latest ruff version (jaraco/skeleton#137)

Jason R. Coombs (14):
      Pin against pytest 8.1.x due to pytest-dev/pytest#12194.
      Migrated config to pyproject.toml using jaraco.develop.migrate-config and ini2toml.
      Allow macos on Python 3.8 to fail as GitHub CI has dropped support.
      Move project.urls to appear in the order that ini2toml generates it. Remove project.scripts.
      Revert "Allow macos on Python 3.8 to fail as GitHub CI has dropped support."
      Rename extras to align with core metadata spec.
      Prefer "Source" to "Homepage" for the repository label.
      Exclude pytest-ruff (and thus ruff), which cannot build on cygwin.
      Re-enable preview, this time not for one specific feature, but for all features in preview.
      Split the test dependencies into four classes (test, cover, type, check). (jaraco/skeleton#139)
      Add upstream and local sections for 'type' extra, since many projects will have 'types-*' dependencies.
      Disable mypy for now. Ref jaraco/skeleton#143
      Finalize
      Remove unsupported attribution. See jaraco/skeleton#144.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants