www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - zip packages to pack modules

reply tcak <1ltkrs+3wyh1ow7kzn1k sharklasers.com> writes:
I brought this feature front before in the forum in someone 
else's post, but it didn't take much attention probably at that 
time.

I want to propose a feature for front-end of the compiler.


The basic definition of feature
===============================
ZIP pack the D module files, and while calling the compiler (dmd, 
gdc, ldc) together with other D source codes, give the zip file. 
The compiler, before doing anything, extracts the modules (and 
sees directories as D package) into a temporary directory or 
memory, and includes those files in the compilation process.


Use Case
========
* Include libraries in a project in one step.
* Versioning is much easier. Programmer creates a library with 
many modules in it. ZIP packs them, and gives a version number to 
it in filename. No more changes will be made on it. (This is my 

* Work of newcomers can be eased.


Why not DUB?
============
I have never use DUB ever, and not planning to use it. Nobody 
else has to use it as well. I don't think anyone should be forced 
for this. The proposed feature allows to simplify downloading 
packages and using them in a projects very quickly and easily 
without needing any tool.


What are the thoughts about this?
Sep 28 2015
next sibling parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 29/09/15 6:24 PM, tcak wrote:

 I brought this feature front before in the forum in someone else's post,
 but it didn't take much attention probably at that time.

 I want to propose a feature for front-end of the compiler.


 The basic definition of feature
 ===============================
 ZIP pack the D module files, and while calling the compiler (dmd, gdc,
 ldc) together with other D source codes, give the zip file. The
 compiler, before doing anything, extracts the modules (and sees
 directories as D package) into a temporary directory or memory, and
 includes those files in the compilation process.


 Use Case
 ========
 * Include libraries in a project in one step.
 * Versioning is much easier. Programmer creates a library with many
 modules in it. ZIP packs them, and gives a version number to it in

 * Work of newcomers can be eased.


 Why not DUB?
 ============
 I have never use DUB ever, and not planning to use it. Nobody else has
 to use it as well. I don't think anyone should be forced for this. The
 proposed feature allows to simplify downloading packages and using them
 in a projects very quickly and easily without needing any tool.


 What are the thoughts about this?


Short answer, no just no.

You could do this so easily as it stands with e.g. bash that it is not 
really a good idea to add a zip library dependency to the front end.
Even though we have it in the standard library.
Sep 28 2015
prev sibling next sibling parent lobo <swamplobo gmail.com> writes:
On Tuesday, 29 September 2015 at 05:24:49 UTC, tcak wrote:

[snip]


 Why not DUB?
 ============
 I have never use DUB ever, and not planning to use it. Nobody 
 else has to use it as well. I don't think anyone should be 
 forced for this. The proposed feature allows to simplify 
 downloading packages and using them in a projects very quickly 
 and easily without needing any tool.


I used to feel this way about DUB too, insisting on my Makefile 
or CMakeD for larger projects. I then tried dub, initially just 
for a quick prototype, but it was so quick, productive and 
seamless to use that I decided to switch immediately.

Now my only regret is that I cannot go back and reclaim the time 
I wasted with other build tools on D projects.

bye,
lobo
Sep 29 2015
prev sibling parent reply bachmeier <no spam.net> writes:
On Tuesday, 29 September 2015 at 05:24:49 UTC, tcak wrote:


 Use Case
 ========
 * Include libraries in a project in one step.
 * Versioning is much easier. Programmer creates a library with 
 many modules in it. ZIP packs them, and gives a version number 
 to it in filename. No more changes will be made on it. (This is 

 * Work of newcomers can be eased.


This could be accomplished by including dub in the default 
installation (already scheduled to happen) and then adding 
something like pragma("dep", ["lib1", "lib2", "lib3"]).

For better or worse, it looks like the decision has been made to 
go with Dub. I think it's a mistake, because (i) it increases the 
learning curve, and (ii) the documentation was not written for 
newcomers (AFAICT the way to learn is to look at existing 
packages and then learn by trial and error). But what I think 
doesn't matter; the decision has been made to use Dub, so there 
is no chance that another approach will be taken.
Sep 29 2015
parent reply wobbles <grogan.colin gmail.com> writes:
On Tuesday, 29 September 2015 at 10:22:05 UTC, bachmeier wrote:

 On Tuesday, 29 September 2015 at 05:24:49 UTC, tcak wrote:


 Use Case
 ========
 * Include libraries in a project in one step.
 * Versioning is much easier. Programmer creates a library with 
 many modules in it. ZIP packs them, and gives a version number 
 to it in filename. No more changes will be made on it. (This 

 * Work of newcomers can be eased.


 This could be accomplished by including dub in the default 
 installation (already scheduled to happen) and then adding 
 something like pragma("dep", ["lib1", "lib2", "lib3"]).

 For better or worse, it looks like the decision has been made 
 to go with Dub. I think it's a mistake, because (i) it 
 increases the learning curve, and (ii) the documentation was 
 not written for newcomers (AFAICT the way to learn is to look 
 at existing packages and then learn by trial and error). But 
 what I think doesn't matter; the decision has been made to use 
 Dub, so there is no chance that another approach will be taken.


How does it increase the learning curve?
Absolutely NOTHING will change when dub is included.
dmd and all your other tools will be there, and you don't have to 
use dub if you don't want to.

Including dub just ensures that everyone can have access to all 
the packages on code.dlang.org easily if they want them. And also 
that we're all working on the same page if we want to create new 
packages.

Personally I feel it's a no brainer to go with dub. Nothing to 
lose and lots to gain.
Sep 29 2015
next sibling parent reply bachmeier <no spam.net> writes:
On Tuesday, 29 September 2015 at 10:37:33 UTC, wobbles wrote:

 How does it increase the learning curve?


A proper package management system would work as I described. You 
include pragma(dub) at the top of your program and you don't have 
to write your own dub package. dub is a substitute for a 
Makefile, not a package manager.


 Absolutely NOTHING will change when dub is included.
 dmd and all your other tools will be there, and you don't have 
 to use dub if you don't want to.


That's the problem. D still won't have a tool to allow you to 
easily use other libraries. Including dub kills off any chance of 
having a package manager.


 Including dub just ensures that everyone can have access to all 
 the packages on code.dlang.org easily if they want them. And 
 also that we're all working on the same page if we want to 
 create new packages.


Again, that's the problem. You shouldn't have to write your own 
dub package in order to use dub, and I shouldn't be forced to 
tell a new D user that this is the documentation to read if they 
want to use D: http://code.dlang.org/package-format?lang=sdl


 Personally I feel it's a no brainer to go with dub. Nothing to 
 lose and lots to gain.


I'm reminded of trying to use Linux in the late 1990's. They 
didn't understand ease of use or documentation either.
Sep 29 2015
parent reply Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 29 September 2015 at 12:04:51 UTC, bachmeier wrote:

 On Tuesday, 29 September 2015 at 10:37:33 UTC, wobbles wrote:


 Again, that's the problem. You shouldn't have to write your own 
 dub package in order to use dub


You don't. You have to write your own dub package in order for 
other
people to use your code with dub.


, and I shouldn't be forced to
 tell a new D user that this is the documentation to read if 
 they want to use D: 
 http://code.dlang.org/package-format?lang=sdl


They don't need that either. `dub init myProj dep1 dep2 ...; dub 
build`. Or
just use git submodules, other people do.

Atila
Sep 29 2015
parent reply bachmeier <no spam.com> writes:
On Tuesday, 29 September 2015 at 14:29:44 UTC, Atila Neves wrote:

 On Tuesday, 29 September 2015 at 12:04:51 UTC, bachmeier wrote:

 Again, that's the problem. You shouldn't have to write your 
 own dub package in order to use dub


 You don't. You have to write your own dub package in order for 
 other
 people to use your code with dub.


How do you use someone else's dub library without using dub 
yourself?


, and I shouldn't be forced to
 tell a new D user that this is the documentation to read if 
 they want to use D: 
 http://code.dlang.org/package-format?lang=sdl


 They don't need that either. `dub init myProj dep1 dep2 ...; 
 dub build`. Or
 just use git submodules, other people do.


Interesting. I wonder if there's a reason it's not documented on 
the website.

"just use git submodules" is not an appealing statement for many 
of those looking at D.

This is no way to organize a critical component of the D 
ecosystem.
Sep 29 2015
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 29 September 2015 at 17:13:26 UTC, bachmeier wrote:

 How do you use someone else's dub library without using dub 
 yourself?


You can always just download it and compile it normally.

dub also has some functions you can use to fetch and add local 
stuff that you could use to download, but then you build your 
program differently.
Sep 29 2015
prev sibling parent Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 29 September 2015 at 17:13:26 UTC, bachmeier wrote:

 On Tuesday, 29 September 2015 at 14:29:44 UTC, Atila Neves 
 wrote:

 On Tuesday, 29 September 2015 at 12:04:51 UTC, bachmeier wrote:

 Again, that's the problem. You shouldn't have to write your 
 own dub package in order to use dub


 You don't. You have to write your own dub package in order for 
 other
 people to use your code with dub.


 How do you use someone else's dub library without using dub 
 yourself?


That's not what I said, nor what I replied to. You said "you 
shouldn't have to write your own package in order to use dub". 
That's not true. Unless you mean you need a dub description to 
use dub, in which case, yes, you do. But as I showed later, it 
can be auto-generated.


 They don't need that either. `dub init myProj dep1 dep2 ...; 
 dub build`. Or
 just use git submodules, other people do.


 Interesting. I wonder if there's a reason it's not documented 
 on the website.


Good question.


 "just use git submodules" is not an appealing statement for 
 many of those looking at D.

 This is no way to organize a critical component of the D 
 ecosystem.


I agree. That's why we have dub.

Atila
Sep 30 2015
prev sibling parent reply tcak <1ltkrs+3wyh1ow7kzn1k sharklasers.com> writes:
On Tuesday, 29 September 2015 at 10:37:33 UTC, wobbles wrote:

 On Tuesday, 29 September 2015 at 10:22:05 UTC, bachmeier wrote:

 On Tuesday, 29 September 2015 at 05:24:49 UTC, tcak wrote:


 Use Case
 ========
 * Include libraries in a project in one step.
 * Versioning is much easier. Programmer creates a library 
 with many modules in it. ZIP packs them, and gives a version 
 number to it in filename. No more changes will be made on it. 

 * Work of newcomers can be eased.


 This could be accomplished by including dub in the default 
 installation (already scheduled to happen) and then adding 
 something like pragma("dep", ["lib1", "lib2", "lib3"]).

 For better or worse, it looks like the decision has been made 
 to go with Dub. I think it's a mistake, because (i) it 
 increases the learning curve, and (ii) the documentation was 
 not written for newcomers (AFAICT the way to learn is to look 
 at existing packages and then learn by trial and error). But 
 what I think doesn't matter; the decision has been made to use 
 Dub, so there is no chance that another approach will be taken.


 How does it increase the learning curve?
 Absolutely NOTHING will change when dub is included.
 dmd and all your other tools will be there, and you don't have 
 to use dub if you don't want to.

 Including dub just ensures that everyone can have access to all 
 the packages on code.dlang.org easily if they want them. And 
 also that we're all working on the same page if we want to 
 create new packages.

 Personally I feel it's a no brainer to go with dub. Nothing to 
 lose and lots to gain.


Selecting a few files with mouse, then click right to create a 
ZIP file cannot be compared writing a DUB package JSON file. I 
would be forgetting how to write it million times, and every 
time, time would be wasted.

If you say that "Hey we want to add meta data to packages", then 
a simple command line flag for dmd can be added like "dmd 
sign-the-package my-library-v1.0.zip". Compiler asks questions, 
you answer them, it generates a sign and puts into zip package. 
Only 1 command line to learn.

What is preventing DUB to use ZIP packages also?

ZIP packages in no way make any change in the language. There is 
no need for pragmas even. There is no this simple (e.g. dmd 
main.d library.zip) substitute for it at the moment.
Sep 29 2015
parent reply ponce <contact gam3sfrommars.fr> writes:
On Tuesday, 29 September 2015 at 14:24:03 UTC, tcak wrote:

 ZIP packages in no way make any change in the language. There 
 is no need for pragmas even. There is no this simple (e.g. dmd 
 main.d library.zip) substitute for it at the moment.


You can do it with a dmd frontend, if an argument finish in .zip, 
then unzip it in a temporary directory, then call dmd.
Passthrough all other flags.

On the other hand, I can only recommend you to use DUB. It made 
things way more simpler than they were, but you do need to learn 
it.
Sep 29 2015
parent karabuta <karabutaworld gmail.com> writes:
On Tuesday, 29 September 2015 at 15:07:40 UTC, ponce wrote:

 On Tuesday, 29 September 2015 at 14:24:03 UTC, tcak wrote:

 ZIP packages in no way make any change in the language. There 
 is no need for pragmas even. There is no this simple (e.g. dmd 
 main.d library.zip) substitute for it at the moment.


 You can do it with a dmd frontend, if an argument finish in 
 .zip, then unzip it in a temporary directory, then call dmd.
 Passthrough all other flags.

 On the other hand, I can only recommend you to use DUB. It made 
 things way more simpler than they were, but you do need to 
 learn it.


dub is more convenient than npm(node package manager) IMHO. Them 
problem is the bloating of dependencies.
Sep 29 2015