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.

Sign up for GitHub

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

Jump to bottom

composer.json - Switch to civicrm/gitignore fork (w/php82+ support) #6

Merged
merged 2 commits into from
Apr 9, 2024
Merged

composer.json - Switch to civicrm/gitignore fork (w/php82+ support) #6

merged 2 commits into from
Apr 9, 2024

Conversation

totten
Copy link
Member

@totten totten commented Apr 9, 2024

togos/gitignore appears to be unmaintained. Switch to fork civicrm/gitignore which includes the patch for php82 (via @seamuslee001) along with other small cleanups.

See also:

@totten
composer.json - Switch to civicrm/gitignore fork (w/php83 support)
cb9e0f0
@totten
Drop support for composer v1
e305f03 
All the PHP code should still be compatible with [email protected]. So why?

* We need to swap-out an abandoned dependency (`togos/gitignore` =>
  `civicrm/gitignore`) to address compatibility w/php82.

* But packagist.org refuses to serve metadata for new dependencies
  (like `civicrm/gitignore`) to [email protected] clients... regardless of
  substantive compatibility.

* So it's a metadata problem (not a code problem). But it still affects
  operations... if [email protected] cannot download then code, then it won't
  work!

* Effectively, it's strict XOR: run cleanly on php82... XOR... keep
  compatibility with [email protected]. Between those, php82 seems more
  important.
@totten
Copy link
Member Author

totten commented Apr 9, 2024

So the first run appears to pass in [email protected] -- but fails on [email protected]. The problem is that packagist.org declines to serve new/current metadata to [email protected]... without the current metadata, you cannot get the underlying code fixes.

So it amounts to a XOR choice: run cleanly on php82... XOR... keep compatibility with composer@1. Between those, php82 seems more important.

(Doing both would require much more... creative juggling? like... bring all the PHPGitIgnore files into composer-downloads-plugin.git? Ugh.)

I don't know how to make the case that composer@1 is important enough to worry about. So I'm pushing up a commit to drop it.

@demeritcowboy
Copy link

I'm personally ok with dropping composer v1. (or better, dropping composer completely... 😈)

@totten
Copy link
Member Author

totten commented Apr 9, 2024

I'm personally ok with dropping composer v1.

Thanks. OK, let's do it.

(or better, dropping composer completely... 😈)

Maybe in next week's patch release... 😉

@totten totten merged commit a1eb770 into master Apr 9, 2024
10 checks passed
@totten totten deleted the master-php83 branch April 9, 2024 20:31
@eileenmcnaughton
Copy link

Do not let @demeritcowboy near composer!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@totten @demeritcowboy @eileenmcnaughton