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

refactor: rename geolocate enginelocate #1263

Merged
merged 1 commit into from
Sep 14, 2023
Merged

refactor: rename geolocate enginelocate #1263

merged 1 commit into from
Sep 14, 2023

Conversation

bassosimone
Copy link
Contributor

@bassosimone bassosimone commented Sep 14, 2023

I am soon going to start addressing the underlying issue described by ooni/probe#2531.

But, before doing that, I have noticed that the packages I need to edit to this end are the following:

./internal/engine
./internal/geolocate
./internal/sessionresolver

Now, these three packages work in unison to provide an engine.Session and they should sort together. However, I would like also to avoid nesting because I think all of them servers an ~independent purpose and geolocate and sessionresolver are possibly building blocks to refactor or reimplement the engine.

For this reason, I have chosen to rename them such that it is clear they are the engine and supporting packages.

This diff addresses the first half of the change by renaming the geolocate package.

While there acknowledge that the script to rename packages was broken and decide to ditch it for good rather than entering into the quest of fixing it. I would probably have spent lots of time trying in doing that, and my time is better spent otherwise. (I remember the official package renaming tool did not support go modules, but probably it does and I should look into giving it another spin.)

I am soon going to start addressing the underlying issue described
by ooni/probe#2531.

But, before doing that, I have noticed that the packets I need to
edit to this end are the following:

```
./internal/engine
./internal/geolocate
./internal/sessionresolver
```

Now, these three packages work in unison to provide an engine.Session
and they should sort together. However, I would like also to avoid
nesting because I think all of them servers an ~independent purpose
and geolocate and sessionresolver are possibly building blocks to
refactor or reimplement the engine.

For this reason, I have chosen to rename them such that it is clear
they are the engine and supporting packages.

This diff addresses the first half of the change by renaming the
geolocate package.

While there acknowledge that the script to rename packages was broken
and decide to ditch it for good rather than entering into the quest
of fixing it. I would probably have spent lots of time trying in doing
that, and my time is better spent otherwise. (I remember the official
package renaming tool did not support go modules, but probably it
does and I should look into giving it another spin.)
@bassosimone bassosimone merged commit 8c0646a into master Sep 14, 2023
6 checks passed
@bassosimone bassosimone deleted the issue/2531 branch September 14, 2023 08:39
Murphy-OrangeMud pushed a commit to Murphy-OrangeMud/probe-cli that referenced this pull request Feb 13, 2024
I am soon going to start addressing the underlying issue described by
ooni/probe#2531.

But, before doing that, I have noticed that the packages I need to edit
to this end are the following:

```
./internal/engine
./internal/geolocate
./internal/sessionresolver
```

Now, these three packages work in unison to provide an `engine.Session`
and they should *sort* together. However, I would like also to avoid
nesting because I think all of them servers an ~independent purpose and
geolocate and sessionresolver are possibly building blocks to refactor
or reimplement the engine.

For this reason, I have chosen to rename them such that it is clear they
are the engine and supporting packages.

This diff addresses the first half of the change by renaming the
geolocate package.

While there acknowledge that the script to rename packages was broken
and decide to ditch it for good rather than entering into the quest of
fixing it. I would probably have spent lots of time trying in doing
that, and my time is better spent otherwise. (I remember the official
package renaming tool did not support go modules, but probably it does
and I should look into giving it another spin.)
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

Successfully merging this pull request may close these issues.

1 participant