-
-
Notifications
You must be signed in to change notification settings - Fork 227
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
remove GeneratorSettings.cache #2703
base: master
Are you sure you want to change the base?
remove GeneratorSettings.cache #2703
Conversation
instead the cache is a property of PackageManager This way dub lib users don't have to try to figure out where the real cache path is and can just continue using the generator and describe APIs like in previous versions. Customizing cache path is no longer easily possible and now must be done through creating a custom PackageManager and use that on `new Project()` to pass into the generators. If needed, APIs to modify m_dirs on startup could be added to Dub subclasses in the future.
✅ PR OK, no changes in deprecations or warnings Total deprecations: 14 Total warnings: 0 Build statistics: statistics (-before, +after)
-executable size=5357768 bin/dub
-rough build time=82s
+executable size=5357832 bin/dub
+rough build time=81s Full build output
|
I take it that there is no possibility of adding a deprecated workaround to give existing users some time to upgrade? |
I don't think there is any way really that wouldn't make the code very ugly, like keeping the old stuff in as second branch (with a lot of copy-pasted code) The API has been released for over 6 months now already so I don't exactly like entirely removing it either. I opted for implementing it this way, since it looked like pretty obviously @Geod24 wanted to get rid of the public access for the cache dir entirely, naming the getter "cachePathDontUse" Nice thing with this PR is at least we are removing that I realized this was an issue because I didn't specify any However actually fixing the cache path to use what DUB uses isn't possible since Alternatively to this PR I could also make it actually use the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I never manage to figure out a way to make it "nice". This approach is a bit of a slippery slope as other places that may need the cache may end up depending on PackageManager
. Instinctively, I think that the cache part should be linked to the Package, but currently the class is not ready for this.
@@ -121,11 +121,13 @@ class ProjectGenerator | |||
protected { | |||
Project m_project; | |||
NativePath m_tempTargetExecutablePath; | |||
PackageManager m_packageMan; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that's the reason I didn't do it in the first place - Having the PackageManager
in the generator is a bit icky.
@WebFreak001 : See #2764 |
instead the cache is a property of PackageManager
This way dub lib users don't have to try to figure out where the real cache path is and can just continue using the generator and describe APIs like in previous versions.
Customizing cache path is no longer easily possible and now must be done through creating a custom PackageManager and use that on
new Project()
to pass into the generators. If needed, APIs to modify m_dirs on startup could be added to Dub subclasses in the future.Also for how the other code was setup, this looks like a more reasonable place to put the code, as well as PackageManager being a good place to handle path modification / generation.
Sadly the GeneratorSettings public API has already been released in a tag and thus this is a breaking change, that for example reggae also uses: https://github.com/atilaneves/reggae/blob/2302be1809edde6e1ac3552ee595970601f960ad/src/reggae/dub/interop/dublib.d#L70
However, at least for reggae, the migration would be trivial, since it already instantiates a custom PackageManager: https://github.com/atilaneves/reggae/blob/2302be1809edde6e1ac3552ee595970601f960ad/src/reggae/dub/interop/dublib.d#L208 and I suppose other apps wanting to control how DUB builds are not using
new Dub
either and instead create custom PackageManager instances.For the usual dub-as-a-library user this PR allows users to start a DUB build, reusing the default DUB cache directory, without hardcoding or copying the DUB cache paths or SpecialDirs implementation from DUB itself. So I think this is definitely a better API than burdening the users with figuring out where the cache should go for builds if they just want to call
dub build
through the API.Note: there was
metadata_cache.json
that still used the old non-central cache path? I moved that into the central cache path now, but maybe @Geod24 knows why this was not yet in the central cache? That part might still need a change.