Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use existing egg as project #8

Closed
rvanlaar opened this issue Dec 27, 2011 · 13 comments
Closed

Use existing egg as project #8

rvanlaar opened this issue Dec 27, 2011 · 13 comments

Comments

@rvanlaar
Copy link
Owner

djangorecipe creates a project specified in the 'project' option in buildout.cfg. It would be very useful to be able to specify an existing egg as your django project. I may have time to implement this if you like the idea.


Imported from Launchpad using lp2gh.

@rvanlaar
Copy link
Owner Author

(by jvloothuis)
Sounds like a good idea. How do you propose this would work (from the config file)?

@rvanlaar
Copy link
Owner Author

(by danfairs)
Instinctively I expected to be able to name an egg which had already been specified elsewhere in the buildout as my 'project' egg in the project line, where you currently specify the project name. I haven't had a close look at the code to know how practical this would be. I wouldn't be averse to a second configuration option, project-egg, with appropriate validation.

You would be able to specify either a regular or a development egg.

I suspect that in fact this option would cause the recipe to do less than it currently does, not more - I suspect it would just affect the content of the generated management script?

@rvanlaar
Copy link
Owner Author

(by jvloothuis)
We could make an option like this:

isegg = true
project = someegg

or:

project = egg:someegg

or:

projectegg = someegg

Guessing it from the existing eggs would be a little to implicit for my liking. It would also mean that we cannot use the feature to fetch the project from an egg index. Since I like the idea of that feature it would be best if we had a way to indicate to the recipe it should use the egg and not some dir it generated. Do you like any of these suggestions or do you have some of your own?

@rvanlaar
Copy link
Owner Author

(by danfairs)

I think I like projectegg best.

isegg = true

  • doesn't feel very nice because it would work by changing the meaning of an existing directive.

project = egg:someegg

  • doesn't feel very nice because it feels like we're inventing a new syntax form (assuming we are? I'm pretty new to buildout, so if prepending egg: means 'this is an egg' elsewhere, we should stick to that).

I guess specifying both projectegg and project together would raise an error? I also assume that the egg specified in projectegg would also have to have been included in the eggs or develop sections, and not doing so would also raise an error?

So I'd be happy with projectegg. I'll try to work up a patch in the next couple of weeks, time permitting, unless you want to go ahead with it yourself?

@rvanlaar
Copy link
Owner Author

(by jvloothuis)
Ok, projectegg it is then. I will be awaiting your patch. If you have any more questions feel free to contact me.

@rvanlaar
Copy link
Owner Author

(by danfairs)
OK, here's a patch that does this. This is my first time with buildout and bazaar, so I'm bound to have done something wrong! I'd anticipate refining this a little before you merge, but I'd appreciate your feedback on whether this is going in the right direction.

There are a couple of things to note here:

  • One of the existing tests which attempted to run 'dir' was breaking on my system (Mac OS X). I replaced it with 'echo', which is there on both. Would be good if you can check this works for you, too.
  • projectegg now works as expected
  • I've included paths generated from the working sets of all the eggs in the buildout in the sys.path for the generated management script - this fixed an issue I was having where Django couldn't find the modules. This was very much 'monkey see, monkey do', so I'm sure there's a better way of doing this. In particular, there's no test yet.
  • I've not yet handled the case of specifying both project and projectegg, and it still creates the project directory even if a projectegg is specified.

Let me know if you're happy with the approach, and I'll tidy up the loose ends above.

@rvanlaar
Copy link
Owner Author

(by jvloothuis)
Thanks for the patch! I will try to look at it in the next few days.

On Mon, Aug 11, 2008 at 11:34 PM, Dan Fairs wrote:

OK, here's a patch that does this. This is my first time with buildout
and bazaar, so I'm bound to have done something wrong! I'd anticipate
refining this a little before you merge, but I'd appreciate your
feedback on whether this is going in the right direction.

There are a couple of things to note here:

  • One of the existing tests which attempted to run 'dir' was breaking on
    my system (Mac OS X). I replaced it with 'echo', which is there on both.
    Would be good if you can check this works for you, too.
  • projectegg now works as expected
  • I've included paths generated from the working sets of all the eggs in
    the buildout in the sys.path for the generated management script - this
    fixed an issue I was having where Django couldn't find the modules. This
    was very much 'monkey see, monkey do', so I'm sure there's a better way
    of doing this. In particular, there's no test yet.
  • I've not yet handled the case of specifying both project and
    projectegg, and it still creates the project directory even if a
    projectegg is specified.

Let me know if you're happy with the approach, and I'll tidy up the
loose ends above.

** Attachment added: "Rough patch adding projectegg support"
http://launchpadlibrarian.net/16713400/djangorecipe-projectegg.diff

Use existing egg as project
https://bugs.launchpad.net/bugs/252647
You received this bug notification because you are a direct subscriber
of the bug.

@rvanlaar
Copy link
Owner Author

(by danfairs)
Slightly improved patch - if projectegg is specified, then don't create the project directory.

@rvanlaar
Copy link
Owner Author

(by danfairs)
OK - last patches made unnecessary paths (the third point from my initial list). This is actually done using the eggs option inside the [djangorecipe] section - this is actually in one of your examples :) D'oh. This patch removes my misfeature.

@rvanlaar
Copy link
Owner Author

(by jvloothuis)
On Tue, Aug 12, 2008 at 11:28 PM, Dan Fairs wrote:

OK - last patches made unnecessary paths (the third point from my
initial list). This is actually done using the eggs option inside the
[djangorecipe] section - this is actually in one of your examples :)
D'oh. This patch removes my misfeature.

How did you create your branch? I seem to have some trouble to do a
checkout. For now I will concentrate on the patch you provided. I had hoped
to keep your version info (and therefore the credits) linked by merging your
branch.

@rvanlaar
Copy link
Owner Author

(by jvloothuis)
After looking at your patch it seems that the only thing needed is to disable project generation. Perhaps an even better option would be something like:

project = someegg
create-project = false

@rvanlaar
Copy link
Owner Author

(by danfairs)
That's somewhat similar to one of the original options. I'm not sure I like it, because it overloads the meaning of 'project', depending on the value of create-project.

With the current implementation, I can't think of a case where you'd want to create the project having specified a value for projectegg. If that's true, then we just need to not create the project when projectegg is specified. Can you think of a case where that would be wrong?

With respect to the branch - I just created it using bzr branch lp:djangorecipe. I'm new to bazaar, so if I need to do the branch creation in different way to help you with the eventual merge, I'm more than happy to do so!

@rvanlaar
Copy link
Owner Author

(by jvloothuis)
The code has been merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant