debian package for pegged

[ikod]

Hello,

I'd like to have debian package for pegged, but can't find any on the network. If you think it is worth of effors I can do all wrapping and pull request.

Thanks!

[PhilippeSigaud]

Hello,

I'd like to have debian package for pegged, but can't find any on the

network If you think it is worth of effors I can do all wrapping and pull
request

Thanks!

Thank you for your offer, but even if the development of Pegged is not as
fast as a few years ago, I still have people contributing code, so you can
expect new (minor) versions of Pegged to get published from time to time
(say, twice a year). Wouldn't that mean a new deb package has to be created
each time I bump the version?
Also, it's already on dub ( https://code.dlang.org ), I thought that was
the main way people distribute code for D?

[ikod]

Wouldn't that mean a new deb package has to be created each time I bump the version?

Yes, but it is as easy as changing two text files and running dpkg-buildpkg

Also, it's already on dub ( https://code.dlang.org ), I thought that was the main way people distribute code for D?

There are several points, please correct me if i'm wrong:

• debian packages is standard way to distribute binaries for debian flavours of linux. It covers lot of aspects of package managing (versions, conflicts, dependencies, building dependencies, etc) and used widely for distributing and deploying software. It is hard to handle two separate distribution methods. For example, if I use debian packaging for software deployment on my servers, I also have to use Dub to build Pegged directly on server.
• Debian packages can distribute binaries, you don't have to set up compiler on each machine. From the other side if you use Dub - you have to compile Pegged sources on each machine.
• Dub for D is like "pip" or "setuptools" for Python - it fetch sources from public repository, compile and install binaries. But majority of python code also wrapped in debian packages.

[veelo]

Hi ikod,

Since you are offering to do the work, I suppose you have the need for a binary distribution. Which suggests you are distributing an application that builds on Pegged, and you want to link to it dynamically, correct? Could you please expand on the way you use Pegged, because it surprises me a little that you would want to package Pegged separately, as a binary.

Since Pegged is essentially a code-generating library, its value is in my eyes mostly in the development of parsers. That suggests a source distribution. The code that ends up in binary form in the parser is contained in one file peg.d, which is just 3k LoC, including a lot of unit tests. It would produce a tiny binary --- is it worth linking to dynamically?

Now, applications that use Pegged and are distributed as a Debian package will need the Pegged source to be built. You could argue that a Debian source package of Pegged would be desirable. But isn't it much more straight forward and generic to make dub a build-dependency and use it in the package recipe to download the appropriate version of Pegged? Pegged doesn't even need to be compiled separately, its files can just be listed as part of the compilation of the main application.

This approach holds for many D libraries, I think. So testing the process and documenting it would be a nice contribution, if you are interested.

Bastiaan.

[ikod]

I distribute small library which use Pegged to parse user requests. I use this library both to link static binaries and to use in shebang D scripts. Right now I realised that distributing Pegged as debian package needed only in the latter case, so that I can install them in the system-wide directory like /usr/include/d/pegged and use shebang line like

#!/usr/bin/rdmd --shebang -I/usr/include/d/
import mylib;
...

And in mylib.d:

import pegged.grammar;

If I can do this (install Pegged files in system-wide directory) using dub, then really I do not need debian packaging.

[veelo]

Thanks for clarifying.

As you would need the source for shebang scripts, this would be a source distribution, not a binary package, right? Like pegged-dev. I am a dub-beginner myself, but I presume it is not meant to put its files in system directories on its own. I do think it should be possible for dpkg to use dub to fetch the files, after which dpkg can do the right thing -- so it could be part of your package. Whether that is a good idea I'm not sure, there is also the issue of package removal.

Maybe this would be a bit backwards though, maybe a Pegged package is indeed more appropriate.

Have you considered asking on the forum what the recommended strategy is for source distribution on Debian, and if and how dpkg and dub should be married?

[PhilippeSigaud]

Maybe this would be a bit backwards though, maybe a Pegged package is
indeed more appropriate.

Have you considered asking on the forum what the recommended strategy is
for source distribution on Debian, and if and how dpkg and dub should be
married?

Yes, it's a subject vaster than Pegged, I'd be interested by what'd be the
D community answer on this.

To answer your original question, if creating a deb package is easy, then
no problem, you're welcome to do it.

Pegged does not depend on cutting edge features of any D compiler, so you
should have no problem generating a binary, whatever compiler you're using.
Did you plan it as a new pull request?

What do you think all: maybe I should put a small explanation concerning
all these 'build/deploy' files, since now there is a valgrind file, a dub
file, a makefile... It seems like anyone has its own idea concerning how
Pegged should be used :-)

[veelo]

On 25 Jan 2016, at 12:01, Philippe Sigaud [email protected] wrote:

What do you think all: maybe I should put a small explanation concerning
all these 'build/deploy' files, since now there is a valgrind file, a dub
file, a makefile... It seems like anyone has its own idea concerning how
Pegged should be used :-)

That might be helpful. I haven’t used any of these though, as I am still just experimenting in the shed. I have used pegged/dev/regenerate.d a couple times, and I keep forgetting the options for rdmd so its output ends up in the right place. Would be nice to have a rule for it in the Makefile, or something.

[ikod]

Thanks for your opinions, all!
I placed question on forum http://forum.dlang.org/thread/[email protected] and will inform you about updates.

[veelo]

One more thing: are your users expected to define their own grammar in the rdmd script, or is the grammar given and fixed? If it is given, it might be better to generate the parser offline using asModule() and your only additional dependency would be peg.d. Then you can also consider distributing a binary version of the parser (I suppose rdmd can link, even statically), so there would be no dependency on Pegged at all --- only on your parser. You would link your application likewise.

[ikod]

One more thing: are your users expected to define their own grammar in the rdmd script, or is the grammar given and fixed? If it is given, it might be better to generate the parser offline using asModule() and your only additional dependency would be peg.d. Then you can also consider distributing a binary version of the parser (I suppose rdmd can link, even statically), so there would be no dependency on Pegged at all --- only on your parser. You would link your application likewise.

Nice idea, will try.

[ikod]

Philippe, following to question, posted on forum -- there were not too much responces, so I'll probably prepare package and then you will decide use it or not.

Thanks!

[veelo]

@PhilippeSigaud

What do you think all: maybe I should put a small explanation concerning
all these 'build/deploy' files

Yes, please, that would have helped prevent #181 (at least its second part).

[PhilippeSigaud]

On Thu, Feb 4, 2016 at 12:44 PM, ikod [email protected] wrote:

Philippe, following to question, posted on forum -- there were not too
much responces, so I'll probably prepare package and then you will decide
use it or not.

Thanks!

I'll include it with pleasure, thanks for your work!

[PhilippeSigaud]

I can do that this week end. A small `build.md` file.

[ikod]

Hello,
I made PR with more or less detailed comment. I placed my name and email as maintainer for debian package as I do not know your email, please feel free to change anything before merge.

Thanks!

[PhilippeSigaud]

Hi, my email is philippe.sigaud with gmail. Since I'm absolutely not competent in any way concerning Debian packages, I prefer to let your email as PoC, if that's OK with you.