RejectedSoftware Forums

Sign up

Problem registering a new package?

I'm pretty new to dub, but a few of my users requested I set things up to work with it and I am having a couple of issues. I've gotten things set up on my own system to where I can test out my stuff locally, but I am encountering this error:

Error adding local package: opApply may only be called on arrays, not String 

I had some issues earlier(json file was missing some things) so I couldn't register my package, but while writing this I managed to get it registered. Should I be testing it that way instead?

Thanks much!

Problem testing with a local package

On Tue, 19 Nov 2013 07:21:08 GMT, Jebbs wrote:

I'm pretty new to dub, but a few of my users requested I set things up to work with it and I am having a couple of issues. I've gotten things set up on my own system to where I can test out my stuff locally, but I am encountering this error:

Error adding local package: opApply may only be called on arrays, not String 

I had some issues earlier(json file was missing some things) so I couldn't register my package, but while writing this I managed to get it registered. Should I be testing it that way instead?

Thanks much!

Renamed the subject because I changed what I was writing about :P

On a side note, I had a branch in my repo that I no longer needed. I deleted it, but now I am getting this error when I tried to update the package in the registry:

Failed to get tags: Failed to read JSON from https://api.github.com/repos/Jebbs/DSFML/tags: Unexpected reply for 'https://api.github.com/repos/Jebbs/DSFML/tags': Forbidden

Anything I can do about that?

Re: Problem testing with a local package

Am 19.11.2013 08:34, schrieb Jebbs:

On Tue, 19 Nov 2013 07:21:08 GMT, Jebbs wrote:

I'm pretty new to dub, but a few of my users requested I set things up to work with it and I am having a couple of issues. I've gotten things set up on my own system to where I can test out my stuff locally, but I am encountering this error:

Error adding local package: opApply may only be called on arrays, not String 

I had some issues earlier(json file was missing some things) so I couldn't register my package, but while writing this I managed to get it registered. Should I be testing it that way instead?

Thanks much!

Renamed the subject because I changed what I was writing about :P

On a side note, I had a branch in my repo that I no longer needed. I deleted it, but now I am getting this error when I tried to update the package in the registry:

Failed to get tags: Failed to read JSON from https://api.github.com/repos/Jebbs/DSFML/tags: Unexpected reply for 'https://api.github.com/repos/Jebbs/DSFML/tags': Forbidden

Anything I can do about that?

That last error looks like the API limit for github was exceeded (there
is only a quite small limit of uncached requests/replies that can be
made each hour). It should work automatically again the hour after, but
it looks like something needs to be done about it soon.

I've taken the look at the package.json file and there are two things
that caught my eye:

  • "importPaths": "scr/" should be "importPaths": ["src/"] - this
    may be where the error message comes from
  • instead of the long list of "sourceFiles", you can also use a
    single "sourcePaths": ["src/dsfml/audio"] etc. for each sub package

I'll try to improve the error messages.

Re: Problem testing with a local package

On Tue, 19 Nov 2013 08:53:32 +0100, Sönke Ludwig wrote:

I've taken the look at the package.json file and there are two things
that caught my eye:

  • "importPaths": "scr/" should be "importPaths": ["src/"] - this

may be where the error message comes from

  • instead of the long list of "sourceFiles", you can also use a

single "sourcePaths": ["src/dsfml/audio"] etc. for each sub package

I'll try to improve the error messages.

Thanks very much! I made the changes, and it seems to have improved things, but I am still getting an error that is preventing me from compiling.

Even with the import paths line to "importPaths": ["src/"], it is telling me that it cannot find dsfml/graphics.d, though it should be dsfml/graphics/package.d instead as that was set up after 2.064 was released. Anything I can do about that?

Also, due to the inability to find the right file, it displays the import paths used for the compilation. The path to the DSFML/src/ directory is not included, so maybe that has something to do with it?

Re: Problem testing with a local package

On Tue, 19 Nov 2013 22:33:58 GMT, Jebbs wrote:

On Tue, 19 Nov 2013 08:53:32 +0100, Sönke Ludwig wrote:

I've taken the look at the package.json file and there are two things
that caught my eye:

  • "importPaths": "scr/" should be "importPaths": ["src/"] - this
    may be where the error message comes from
  • instead of the long list of "sourceFiles", you can also use a
    single "sourcePaths": ["src/dsfml/audio"] etc. for each sub package

I'll try to improve the error messages.

Thanks very much! I made the changes, and it seems to have improved things, but I am still getting an error that is preventing me from compiling.

Even with the import paths line to "importPaths": ["src/"], it is telling me that it cannot find dsfml/graphics.d, though it should be dsfml/graphics/package.d instead as that was set up after 2.064 was released. Anything I can do about that?

Also, due to the inability to find the right file, it displays the import paths used for the compilation. The path to the DSFML/src/ directory is not included, so maybe that has something to do with it?

Okay, I've got it working now on Windows up to the linker stage, because I didn't build the C library. There was one issue in DUB that is fixed on GIT master and I've modified the DSFML's package.json a bit:

{
	...
	"license": "Zlib",
	"dependencies": {
		"dsfml:audio": "~master",
		"dsfml:graphics": "~master",
		"dsfml:network": "~master"
	},
	"sourcePaths": [],
	"importPaths": [],
	"subPackages": [
	...

The "dependencies" field was missing, so that a dependency "dfsml" could simply be added instead of each sub package individually, and the parent package should actually have no source and import paths specified (it shouldn't matter, but they would then be passed to the compiler twice, once for the parent package and one for the sub packages).

With this, I'm now just getting "File Not Found dsfml-audio.lib" and "Symbol not found" like errors.

Re: Problem testing with a local package

On Wed, 20 Nov 2013 08:12:09 GMT, Sönke Ludwig wrote:

On Tue, 19 Nov 2013 22:33:58 GMT, Jebbs wrote:

On Tue, 19 Nov 2013 08:53:32 +0100, Sönke Ludwig wrote:

I've taken the look at the package.json file and there are two things
that caught my eye:

  • "importPaths": "scr/" should be "importPaths": ["src/"] - this
    may be where the error message comes from
  • instead of the long list of "sourceFiles", you can also use a
    single "sourcePaths": ["src/dsfml/audio"] etc. for each sub package

I'll try to improve the error messages.

Thanks very much! I made the changes, and it seems to have improved things, but I am still getting an error that is preventing me from compiling.

Even with the import paths line to "importPaths": ["src/"], it is telling me that it cannot find dsfml/graphics.d, though it should be dsfml/graphics/package.d instead as that was set up after 2.064 was released. Anything I can do about that?

Also, due to the inability to find the right file, it displays the import paths used for the compilation. The path to the DSFML/src/ directory is not included, so maybe that has something to do with it?

Okay, I've got it working now on Windows up to the linker stage, because I didn't build the C library. There was one issue in DUB that is fixed on GIT master and I've modified the DSFML's package.json a bit:

{
	...
	"license": "Zlib",
	"dependencies": {
		"dsfml:audio": "~master",
		"dsfml:graphics": "~master",
		"dsfml:network": "~master"
	},
	"sourcePaths": [],
	"importPaths": [],
	"subPackages": [
	...

The "dependencies" field was missing, so that a dependency "dfsml" could simply be added instead of each sub package individually, and the parent package should actually have no source and import paths specified (it shouldn't matter, but they would then be passed to the compiler twice, once for the parent package and one for the sub packages).

With this, I'm now just getting "File Not Found dsfml-audio.lib" and "Symbol not found" like errors.

Awesome! Thank you so very much for all the help. I'll try it later today once I get home from work, but that should be all that I need.

You rock!

Re: Problem testing with a local package

Just wanted to let you know that I was able to get everything up and running for building a DSFML application via dub! You helped a lot! Instead of adding the sub packages as dependencies to the main dsfml package, I decided to go a slightly different route.

I added the importPaths to the system sub package since it is a dependency of every other sub package, and then my test application json looks like this:

{
	"name": "dubtest",
	"description": "Testing DSFML and DUB!",
	"copyright": "Copyright © 2013, Jeremy",
	"authors": ["Jeremy"],

	"lflags" : ["+C:\\Users\\Jeremy\\Dropbox\\dsfml\\"],

	"dependencies": 
	{
		"dsfml:graphics": "~master"
	}

	
}

This works, and is great. It is pretty much exactly what I would want since each part of DSFML is split up into different parts.
The reason I am making this post is because of what the package information page says about using it in someone's own project.

It says to include this bit in the users dub json:

{
	...
	"dependencies": {
		"dsfml": "~master"
	}
}

Is there any way we can manually override that part of the page and provide our own example if the package.json for the library is set up in a different way than what you normally expect?

Re: Problem testing with a local package

Am 21.11.2013 21:22, schrieb Jebbs:

Just wanted to let you know that I was able to get everything up and running for building a DSFML application via dub! You helped a lot! Instead of adding the sub packages as dependencies to the main dsfml package, I decided to go a slightly different route.

I added the importPaths to the system sub package since it is a dependency of every other sub package, and then my test application json looks like this:

{
	"name": "dubtest",
	"description": "Testing DSFML and DUB!",
	"copyright": "Copyright © 2013, Jeremy",
	"authors": ["Jeremy"],

	"lflags" : ["+C:\\Users\\Jeremy\\Dropbox\\dsfml\\"],

	"dependencies": 
	{
		"dsfml:graphics": "~master"
	}

	
}

This works, and is great. It is pretty much exactly what I would want since each part of DSFML is split up into different parts.
The reason I am making this post is because of what the package information page says about using it in someone's own project.

It says to include this bit in the users dub json:

{
	...
	"dependencies": {
		"dsfml": "~master"
	}
}

Is there any way we can manually override that part of the page and provide our own example if the package.json for the library is set up in a different way than what you normally expect?

I'd highly recommend to add all sub packages as dependencies to the main
package. This way, you'll provide a convenient and intuitive means to
use it when all packages are needed anyway, and the dependencies will
also be listed on the package page on the registry, giving a hint that
it's also possible to only use individual sub packages.

The page for each sub package then contains the proper instructions for
using only that sub package (e.g.
http://code.dlang.org/packages/dsfml:graphics), but sub packages are
currently not listed explicitly, only as dependencies (that will change,
though).

Other than that, it's also planned to display the README.md of the
repository on the package page, so detailed installation instructions
can also be listed there in the future.