search

MeteorPackaging / discussions

Ask for Meteor integration help, or discuss Meteor 3rd party library packaging
5 stars 1 forks source link

jsPDF #18

Open chip opened 9 years ago

chip commented 9 years ago

According to the Meteor Packaging wiki, I'm supposed to "File an issue in MeteorPackaging/discussions and ask for permission to fork the repo into the MeteorPackaging org".

I would like to start with jsPDF - https://github.com/MrRio/jsPDF

As a side note, I recently published chipcastledotcom:jspdf on Atmosphere, but followed the git submodule approach, which was done prior to reading several posts on how I should contact you instead and follow the instructions on the wiki. Any pointers on deprecating that package would be helpful as well. I figured I would just update the README and point to the package once it's published properly.

Thank you for your assistance. :+1:

splendido commented 9 years ago

Hello @chip! @dandv recently pushed to switch to the sister repo approach, and I think it could be a way to go: see #16

Based on what you prefer I can fork the original package on MeteorPackaging, or create a new repo so that you can send over your files.

Let me know

chip commented 9 years ago

@splendido - Thanks for the info! If I understand it correctly, I would need to add a package.json for the meteor publish part and also adjust my package.json to automatically detect a version number.

In any event, if @dandv is pushing the sister approach, I'm happy to comply. Let me know what else I should do. Thanks again.

chip commented 9 years ago

As a side note, once the integration of jsPDF is completed, I'm considering wrapping these as Meteor packages as well:

The 2 jsPDF repo maintainers have recently merged other PR's from me, so I'm hopeful that they'll continue to be responsive in terms of this effort. Thanks again for your assistance with this, Luca!

splendido commented 9 years ago

If you think the official maintainers will be responsive to a PR to get official integration, we can try something on the line of past successful integrations

What if you ping the maintainers and ask whether they would be available to accept a PR similar to the above linked ones? In case you get a no go, we can proceed with the sister repo approach.

Thoughts?

chip commented 9 years ago

The author of jsPDF-AutoTable already responded positively, which is great news. :+1:

If I understand this process correctly, all that is needed is for me to do is follow the instructions on the wiki after the repo is created under the MeteorPackaging organization. Please confirm this or let me know if there's a better way.

As a side note, it appears that someone already forked jsPDF back in January. Does that mean I should move forward with the wiki instructions or let someone else spearhead the effort?

splendido commented 9 years ago

the fork is by @dandv on Feb 6, but it seems there's no activity on it since then... I also see nothing on atmosphere that might have came for that repo.

For me it's a go!

...it seems the build is done with a sh script: you might want to have a look to previous integration using Makefiles to get inspired ;-)

splendido commented 9 years ago

as for point 14. of the instructions, it might be better to agree on the organization/package name with the author before publishing the first official version. This shouldn't be a problem since you're already discussing about this integration with him...

chip commented 9 years ago

It looks like you already created a jsPDF organization name, which I think is fine, but if you want me to check with the original author, I'll do that. Just LMK.

Regarding jspdf-autotable, I just pinged the author to get his thoughts.

chip commented 9 years ago

BTW, I still need https://github.com/someatoms/jsPDF-AutoTable forked under MeteorPackaging when you get a chance. Thanks @splendido!

splendido commented 9 years ago

...I'm sorry I wasn't aware of jsPDF organization: as you can see it wasn't me ;-) So just confirm with the author something like jspdf:core is fine. ...the idea might be to then have jspdf:auto-table. Does this make sense?

@dandv could you add meteorpublish to the jsPDF org?

splendido commented 9 years ago

@chip, here you go: jsPDF-AutoTable

chip commented 9 years ago

Perfect! Thanks Luca! :+1:

chip commented 9 years ago

@splendido - I'm currently on step 9 of the wiki and see that there are no tests and there is no Gruntfile.js, so I'm not sure what to do. There is a bower.json, BTW. Any suggestions are appreciated. Thank you.

chip commented 9 years ago

@splendido or @dandv - When you get a chance, could I get a little assistance on my bower question above for step 9? Thanks.

splendido commented 9 years ago

...well, the thing is it seems he-s not keeping the version number anywhere else than in the release name :(

I guess we should ask him whether he's willing to keep a package.json or something to track the release number more explicitely

chip commented 9 years ago

Thanks for spotting that. I see other packages like ionic which have hard-coded version numbers in package.js, package.json and bower.json, so I guess we could do the same here. I also see that FontAwesome does something more dynamic, but it does appear to be a bit complicated. Your thoughts?

splendido commented 9 years ago

The thing is: in case the author accepts the PR, it will be his own responsibility to manually update the version number accordingly with the release number he's going to release...

Percentage probability of fault? above 90% ;-)

splendido commented 9 years ago

@chip, perhaps we'd better complete all the discussions here before bothering original authors...

How are things for jspdf:jspdf? Should we finish with this before going on with the plugins?

chip commented 9 years ago

@splendido - I agree. I was holding off on jspdf:jspdf because I thought jspdf:autotable would be easier to implement due to it's smaller size and limited dependencies. I must admit that I wasn't completely clear how to proceed on this due to the overwhelming discussion on packaging, but from various lengthy issues and wiki pages I was able to cobble together that PR for jspdf:autotable.

I guess my biggest question going forward is should I follow the Wiki and create the package on atmosphere and push my changes to the fork, or should we wait for Simon to merge in my PR on the original repo?

I think it would help me greatly if I could solidify an approach and see the build work on autopublish.meteor.com work successfully.

Regarding jspdf:jspdf, I'll go ahead and attempt a PR for that. Please feel free to give me pointers on anything. Thank you for your continued support!

chip commented 9 years ago

@splendido - Sorry for multiple posts, but I just reviewed your comment on my PR, so I'll get to work on that soon.

splendido commented 9 years ago

No worries! I agree we should choose a method and go with it.

What do you think about this solution? See also #16.

I might try to automatize the trigger process tomorrow or this next week, but we could publish instantly without having to wait for PRs and the like...

chip commented 9 years ago

Very interesting. I'm still not clear on the entire process, so let me explain how I think this works and you can fill in the blanks for me. :)

  1. You or someone else on the Meteor Packaging team would create a new repo with the appropriate package name (e.g., https://github.com/MeteorPackaging/jsPDF.git). This part is already done for jsPDF, so I think we're in good shape here.
  2. That repo would ONLY contain files that you specified in https://github.com/MeteorPackaging/autopublish-test-sister, which means that the repo would only include README.md, gulpfile.js, package.js, package.json and publish.sh. These boilerplate files would need to be edited to suit the package name accordingly.
  3. For example purposes, here's what I think these files would be for jsPDF:

README.md

Generate PDF files in JavaScript. HTML5 FTW. http://jspdf.com/

Meteor package installation:
meteor add jspdf:core

gulpfile.js Same as https://github.com/MeteorPackaging/autopublish-test-sister/blob/master/gulpfile.js

package.js

Package.describe({
  name: 'jspdf:core',
  summary: 'Generate PDF files in JavaScript. HTML5 FTW. http://jspdf.com/',
  version: '1.0.272',
  git: 'https://github.com/MeteorPackaging/jsPDF.git'
});

Package.onUse(function(api) {
  api.versionsFrom('1.0.1');
  api.addFiles('upstream/dist/jspdf.debug.js');
});

# Package.onTest not used because jsPDF build process on original repo runs tests

package.json Same as https://github.com/MeteorPackaging/autopublish-test-sister/blob/master/package.json

publish.sh

git clone --branch master --depth 1 --single-branch https://github.com/MeteorPackaging/jsPDF.git upstream
npm install
gulp
meteor publish

Here's how I understand it currently:

  1. The publish.sh would be triggered whenever the original repo has something pushed to or merged into the master branch (or whatever branch they're using for releases). The original author would need to sign up at http://autopublish.meteor.com/ for an account and then enable their repo under the account for the Github webhook to be setup. If they don't do this how would we initiate the webhook?
  2. The publish.sh would clone the branch into an upstream directory on the machine where autopublish.meteor.com runs.
  3. Then npm install would read package.json and install the devDependencies (i.e., gulp, gulp-replace).
  4. Then gulp would read the gulpfile.js to extract the package version found within upstream/package.json and use that number to replace what is in package.js so they stay in sync with the original repo and also so that a new version is recognized by Atmospherejs.com. However, what happens if the original author doesn't include a version in package.json or even have that file in the repo? I assume that this will require a PR to be merged into the original repo, but what do we do if it's never merged?
  5. Finally, the publish.sh will run meteor publish, pushing up the new version of the package.
  6. End users would be encouraged to install packages approved by MeteorPackaging, so in this case for jspdf they would do something like this:

meteor add jspdf:core

That would pull from Atmospherejs.com since you've already setup the jspdf namespace.

Wow! Sorry for that lengthy explanation, but I felt it helped to lay out my thoughts here just to make sure I understand this. If I'm mistaken, please let me know.

Thanks again!

splendido commented 9 years ago

Very good summary! I think you got it right :) ...the only thing is that what's now included in publish.sh could be run by autopublish as the sequence of commands needed on the build machine to get the package published.

to answer your two question marks:

1) if we don't get the webhook (but reasonably we should, since it has no costs for the developers...) we can also try to poll for the latest available release of a repository using the GitHub API: see latest reelase and self-trigger in case this has changed from the last time.

2) for libraries without an explicit version number, we might use the release tag. So we should check that at least we get a semver compliant version number from a file of from the release names.

I'll try to complete the Gulp file adding a checkout task to be used to clone the upstream repo at the required tag.

I'm also thinking about turning the package.json file into an autopublish.json one to both keep things clearer and have a mean to distinguish such a kind of repo for the autopublish.meteor.com interface (now I'm using the presence of package.js to check whether the repo might be a Meteor package or not...).

chip commented 9 years ago

Ha! Yeah, sorry for the long notes on my previous message. I appreciate you reading all of it since I couldn't think of a TLDR version.

Regarding the latest release API, I think that's a reasonable approach. Hopefully we won't need it from most library maintainers.

Also, I really like your idea of using an autopublish.json because some packages already have a package.json, so this helps distinguish it that it's for use with Meteor.

I'll wait for you to finish the Gulp file and autopublish.json before moving forward with the other integrations. Please LMK if I can help you in any way. Thanks!

splendido commented 9 years ago

I've updated a bit the content of the sample sister repo.

Could you please try starting off it with jspdf:core?

splendido commented 9 years ago

Hei @chip, I've just created the jspdf-core-wrapper repo.

Feel free to initialize it! I might try to get it up and working later on... lets see who gets there first ;-)

chip commented 9 years ago

Thank you Luca! I initialized it and pushed up a commit to the autopublish branch. It's just the boilerplate files which I'll need to edit. Will circle back a bit later.

Thank you,

Chip Castle http://chipcastle.com chip@chipcastle.com (Email/Google Hangouts) chipcastle (Skype) 850-225-0552 (Cell)

On Wed, May 6, 2015 at 5:01 PM, Luca Mussi notifications@github.com wrote:

I've updated a bit the content of the sample sister repo.

Could you please try starting off it with jspdf:core?

— Reply to this email directly or view it on GitHub https://github.com/MeteorPackaging/discussions/issues/18#issuecomment-99622059 .

splendido commented 9 years ago

@chip about jspdf-AutoTable: here you go! ;-)

chip commented 9 years ago

Sweet. Thanks Luca!

chip commented 9 years ago

I've pushed my work up directly to master since it was a blank repo. Please review when you have time and LMK if there are any revisions necessary. I think we still need Dan to open permissions on the Atmosphere jspdf namespace before these packages will be available for others.

splendido commented 9 years ago

I've just wrote @dandv an email: hopefully we'll gain access to jspdf very soon! :-) I'll try to revise your work this evening...

splendido commented 9 years ago

@chip I've wokred a bit on the two repos... ...I've pushed a number of commits: I hope you don't mind! Your PR were much more elegant, for sure! We might think to recreate them for scratch and push with the least number of commits if you wish.

I'm still not that satisfied with the gulpfile but I had enough for today... I'd like to create a checkout tasks which rus the sequence getUpstream, updateVersion, updateRelease but I'm getting some problem with asynchronisms... :(

Btw, now:

  1. npm install
  2. gulp getUpstream
  3. gulp test

should be enough to get the package up and running...

Beware: you need panthomjs installed on the system for tests to work properly. Beware 2: to test jspdf:autotable you need to export the PACKAGES_DIR pointing where you have jspdf:core

chip commented 9 years ago

@splendido - Thanks for pushing your commits. They look great! I haven't had a chance to test this out yet, but plan to do so soon.

A few days ago jspdf:core was available via the command line, but it doesn't work any longer. Do you have any idea about what happened there?

Also, do you think we're ready for me to contact the owner of jsPDF to get the webhook setup?

Thanks.

chip commented 9 years ago

@splendido - When you get a spare moment, would you please respond to the questions in my last comment?

splendido commented 9 years ago

hey @chip, sorry for the late reply.

To be able to test jspdf:autotable locally you should run

export PACKAGE_DIRS="path/to/the/folder/containing/local/packages"

before running meteor test-packages ./ inside the folder with jspdf:autotable.

I'd say it's fine to contact the author and ask for the webhook! Feel free to propose a standard text on the lines of this one to ask for manually creating webhooks. See also this page containing some instructions you can link within the text.

Unfortunately I had no time to update autopublish.meteor.com to let people automatically create hooks also for repositories not containing meteor packages...

chip commented 9 years ago

I just updated the issue for jspdf, but revised some of the text since our process has changed somewhat. I just noticed that we still don't have the package on Atmosphere, so I provided a link to the organization instead. Is this something you can fix or do we need to bring in dan?

splendido commented 9 years ago

hi @chip! ...I wanted to complete the integration process for the new wrappers this morning, but I've lost a bunch of time trying to get tests working on my DO droplet :( At least they're now working! :)

I've read the new text: the only wrong part is the one at point 2. which won't be possible for MrRio since the repository will not be recognized as a meteor package (no package.js present on the root of the repository...). The only way for him to create a webhook right now is to do it by hands, as somewhat explained here.

I hope to be able to complete the integration soon!

...if you wish we can publish the package right now! I'm going to add you to the jspdf organization.

splendido commented 9 years ago

...what's your meteor developer username?? (chip doesn't exist...)

chip commented 9 years ago

My meteor developer username is chipcastle.

splendido commented 9 years ago

Done! I'll leave you the honour to create the jspdf:core package! ...and, at this point, also jspdf:autotable ;-)

splendido commented 9 years ago

...whatmore, you should now be able to edit the jspdf page on atmosphere!

chip commented 9 years ago

Nice! Thank you. :smile:

jspdf:core is now published! https://atmospherejs.com/jspdf

chip commented 9 years ago

jspdf:autotable is now published as well.

@splendido - I have a few questions based on the results of running meteor search jspdf:

Matching packages:                            
chipcastledotcom:jspdf            Meteor package for wrapping jsPDF
chipcastledotcom:jspdf-autotable  Meteor package for AutoTable plugin to jsPDF
chipcastledotcom:meteor-jspdf     Meteor package for wrapping jsPDF
jspdf:autotable                   jsPDF-AutoTable (official): generate PDF tables on the client-side (jspdf:core...
jspdf:core                        jsPDF (official): Generate PDF files on the client-side
local-test:jspdf:autotable        jsPDF-AutoTable (official): generate PDF tables on the client-side (jspdf:core...
  1. I plan on deprecating my company's packages, which are under the chipcastledotcom username, by updating the README for those repos after I test the Official packages more fully. Once that is complete, should I also remove them from the meteor search jspdf results? If so, how is that done?
  2. What is local-test:jspdf:autotable? I cannot find it on my local system or on atmospherejs and thought you might have an idea.
  3. What are the next steps for autopublish for these packages? Is there something I can assist you with?
splendido commented 9 years ago

awesome!

1) you'd have to run meteor admin set-unmigrated chipcastledotcom:jspdf and the likes to hide them from both meteor search and atmosphere: this is actually a trick since the packages will still exist and can be installed on direct request, but at the moment there's no way to delete a package!

2) I have no idea, but I'd have bet you had the wrapper repository available from your cwd when you run meteor search. Lets try to move to another folder or get rid of the PACKAGES_DIR env variable before runnin meteor search jspdf again...

3) ...there's a lot to do actually. have you had a chance to read a bit of the code here? It's a bit of a ugly code base though... Do you have any experience with the ssh2 npm package? I'd like to get rid of ssh2shell and refactor the Host object...

In any case we could start to organize things a little better and write something down about the design and the implementation?

chip commented 9 years ago

Thanks for the suggestions above. :+1:

Re: autopublish, please point me in the direction of a roadmap or notes you have on how you'd like to refactor the Host object and/or how the ssh2 package should be used in this project. I'll try my best to help where I can.

splendido commented 9 years ago

I'll try to write something more about this tomorrow (time to bed here...). Another page to beef up could be this hackpad: feel free to write whatever come/came to your mind during these last weeks.

splendido commented 9 years ago

hey @chip, sorry for my black out... It's a hard period for me :(

I just searched for jspdf on Atmosphere: what do you think, might this be a good time to unmigrate your packages and also ask manuelschoebel to do the same with his one?

Btw, last week I completed the update of autopublish.meteor.com to support different kind of packages (regular ones and wrappers to be find under MeteorPackaging) plus the creation of webhooks only. the only missing thing right now is the triggering of the publish process both after having received a hook or after regular polling for new releases...

chip commented 9 years ago

Hey Luca, no worries!

I just unmigrated those packages, but I still see a few issues that are a concern:

I'm going to hold off on contacting manuelschoebel until these issues have been resolved. Any suggestion are appreciated. Thanks!

splendido commented 9 years ago

Hey @chip! I'm sorry I'm not going to regularly check the web in the next month... I'm going to get merried on Saturday and I'll be in California for my honeymoon the next month or so...

The integration for new wrapper packages on autopublish is at a good point though, but the actual publish flow is still to be written. I had to refactor the code to be able to distinguish from regular packages and wrapper packages, and also let the possibility to just create webhooks.

Right now, logged in users can choose whether to enable a repository (containing a Meteor package) for autopublishing or simply create a webhook (from any repo). We'd need webhooks from our upstreams repositories to be able to automatically trigger new updates. So, feel free to ask for a simple webhook creation for jspdf:core!

Also, please manually publish updates for jspdf:* in case there will be some in the next month

Quick answers to your points:

Let me know if you can get to a better status with the packages!

chip commented 9 years ago

Hey Luca,

I'll review this in detail later, but just wanted to get back to you since you'll be offline for a while.

I hope you have a great trip to California and congratulations on getting married!

I'll keep an eye on these packages and hope to move things forward.

Take care, Chip

Thank you,

Chip Castle http://chipcastle.com chip@chipcastle.com (Email/Google Hangouts) chipcastle (Skype) 850-225-0552 (Cell)

On Thu, Jun 18, 2015 at 11:02 AM, Luca Mussi notifications@github.com wrote:

Hey @chip https://github.com/chip! I'm sorry I'm not going to regularly check the web in the next month... I'm going to get merried on Saturday and I'll be in California for my honeymoon the next month or so...

The integration for new wrapper packages on autopublish is at a good point though, but the actual publish flow is still to be written. I had to refactor the code to be able to distinguish from regular packages and wrapper packages, and also let the possibility to just create webhooks.

Right now, logged in users can choose whether to enable a repository (containing a Meteor package) for autopublishing or simply create a webhook (from any repo). We'd need webhooks from our upstreams repositories to be able to automatically trigger new updates. So, feel free to ask for a simple webhook creation for jspdf:core!

Also, please manually publish updates for jspdf:* in case there will be some in the next month

Quick answers to your points:

-

set unmigrated has effects only on Atmosphere, lets say. You'll be still able to add the package to any project in case you really want to. There's no way to delete Meteor packages, this unmigrate flag is just a trick to get them hidden at least on Atmosphere...

thanks for sharing the info

autopublish.meteor.com is regularly receiving the triggers, but there's no response at the moment. I'll have to write the last piece of code for this...

to update the docs on atmosphere I guess you should try to update the documentation of your package with meteor publish --update (run meteor help publish for more info).

Let me know if you can get to a better status with the packages!

— Reply to this email directly or view it on GitHub https://github.com/MeteorPackaging/discussions/issues/18#issuecomment-113202509 .