Package in local-packages not picked up after moving package into new directory structure #2691
Comments
|
This is a bogus warning introduced by #2610. It should really only apply to the package cache path(s) (e.g. |
|
@s-ludwig : Actually, it's not a bogus warning, but it is a bug introduced in #2610 . |
Currently, we issue a warning asking people to migrate, but the migrated path is not actually recognized. It was suggested in the issue to ignore this warning for add-path. However, as add-path is a rather low-level use, I think it is better to impose the same condition for managed and unmanaged path, in order to be able to provide the same guarantees. For example, once we move to reading version from the path, we can provide the same speedups for add-path users. We can also make sure that add-path users don't have surprises when dealing with packages that expect a certain structure outside their directory, such as arsd and ae. Some tests were updated with the new path, however, as many will likely be rewritten with the new test framework, and a lot of tests are affected, not all of them were updated, providing coverage for the old and new code alike.
|
Fix: #2780 |
Currently, we issue a warning asking people to migrate, but the migrated path is not actually recognized. It was suggested in the issue to ignore this warning for add-path. However, as add-path is a rather low-level use, I think it is better to impose the same condition for managed and unmanaged path, in order to be able to provide the same guarantees. For example, once we move to reading version from the path, we can provide the same speedups for add-path users. We can also make sure that add-path users don't have surprises when dealing with packages that expect a certain structure outside their directory, such as arsd and ae. Some tests were updated with the new path, however, as many will likely be rewritten with the new test framework, and a lot of tests are affected, not all of them were updated, providing coverage for the old and new code alike.
Currently, we issue a warning asking people to migrate, but the migrated path is not actually recognized. It was suggested in the issue to ignore this warning for add-path. However, as add-path is a rather low-level use, I think it is better to impose the same condition for managed and unmanaged path, in order to be able to provide the same guarantees. For example, once we move to reading version from the path, we can provide the same speedups for add-path users. We can also make sure that add-path users don't have surprises when dealing with packages that expect a certain structure outside their directory, such as arsd and ae. Some tests were updated with the new path, however, as many will likely be rewritten with the new test framework, and a lot of tests are affected, not all of them were updated, providing coverage for the old and new code alike.
Currently, we issue a warning asking people to migrate, but the migrated path is not actually recognized. It was suggested in the issue to ignore this warning for add-path. However, as add-path is a rather low-level use, I think it is better to impose the same condition for managed and unmanaged path, in order to be able to provide the same guarantees. For example, once we move to reading version from the path, we can provide the same speedups for add-path users. We can also make sure that add-path users don't have surprises when dealing with packages that expect a certain structure outside their directory, such as arsd and ae. Some tests were updated with the new path, however, as many will likely be rewritten with the new test framework, and a lot of tests are affected, not all of them were updated, providing coverage for the old and new code alike.
This fixes issue #2691 properly by just silencing the bogus warnings and scanning as always. There is no reason in expecting or supporting the same sub directory structure as for managed paths.
Reverts to the scanning/warning behavior that was in place before the warnings for the new package directory structure were implemented.
Just to also mention it here. This makes absolutely no sense. The main use case for |
Reverts to the scanning/warning behavior that was in place before the warnings for the new package directory structure were implemented.
Reverts to the scanning/warning behavior that was in place before the warnings for the new package directory structure were implemented.
Properly fix issue #2691 by reverting to the original scanning behavior
System information
Bug Description
Dub issues a warning that the current package is at the wrong path. After moving the package to the suggested directory, dub doesn't see the package anymore.
Example:
Warning Package at path '/home/alice/src/dlang-packages/ddbus/' should be under '/home/alice/src/dlang-packages/foo/$VERSION/foo'After move the package into the suggested directory, dub doesn't see the package anymore.
How to reproduce?
dub add-path <path>$HOME/.dub/packages/local-packages.jsonand make sure the path is listed.dub listPackage at path <path>/foo should be under <path>/$VERSION/foodub listWhen trying to build a project it will not pick up the dependency.
Expected Behavior
Dub does see the package after moving it into the suggested directory.
The text was updated successfully, but these errors were encountered: